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ABSTRACT 



This thesis analyzes the current management information systems in place at Silas 
B. Hays Army Community Hospital with in depth research into the hospital’s largest 
department, the Department of Family Practice and Community Medicine. The findings 
of the research indicate these systems are not meeting the needs of department 
managers within the hospital. This thesis contains a requirements analysis for an 
improved information system for the department. The process of identifying the 
targeted users, selecting the appropriate development methodology, and identifying the 
user’s information requirements is discussed. The value of the information required by 
the department manager, both in content and format, is examined. The requirements 
analysis is based on a combination of systems development life cycle and prototyping 
methodologies for information systems development and can be used to design, 
construct, and implement an information system for the targeted department. The 
requirements analysis can also be used to study the expandabihty of the proposed 
information system to departments throughout Silas B. Hays Army Community 
Hospital. 
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I. INTRODUCTION 



A. BACKGROUND 

Silas B. Hays Army Community Hospital (SBHACH) is a large, full service 
medical department activity (MEDDAC) providing health care to active duty, retired, 
and dependent personnel living in and around Fort Ord. The MEDDAC also provides 
regional medical services to personnel from Hunter Liggett Military Reservation, 
Presidio of Monterey, Sacramento Army Depot, United States Naval Postgraduate 
School, and the Sharpe Army Depot. SBHACH’s annual operating budget is over seven 
million dollars and in fiscal year 1988, over 460,000 patients were treated. The 
hospital consists of 13 major medical departments which provide inpatient and 
outpatient service, major surgical services, military medical support, and veterinary 
service. In addition, SBHACH is a teaching hospital for Army doctors and provides 
occupational health to civilian employees. The goal of SBHACH is to provide its 
patients with the best medical care possible. 

The quality of the medical care provided depends on factors such as the quality 
of the hospital personnel and the effective use of available resources, e.g. personnel, 
money, time, and medical supplies. Another factor, the efficient use of resources, 
indirectly affects the quality of care provided because this factor will determine the 
continued availability of the resources. One of the biggest obstacles SBHACH faces 
in trying to reach its goal is the limited resources with which it must operate. 
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SBHACH doctors and administrators must constantly deal with resource 
constraints. They are continually searching for more efficient and effective resource 
management to deal with these constraints while, at the same time, improving the 
quality of care provided to the patients. In searching for the balance between cost 
efficiency and quality of care, hospital administrators are turning to information 
systems, both automated and manual, in the belief that better information wUl help 
them operate more cost effectively. 

B. PURPOSE 

The purpose of this thesis is to study the current management information systems 
in place at Silas B. Hays Army Community Hospital and determine if these systems 
are meeting the needs of department managers within the hospital. In identifying the 
requirements of key department decision makers, we will propose improvements to the 
information system where the current system fails to meet the department manager’s 
needs. Ultimately, the thesis wUl provide a design for an information system which will 
meet the needs of department decision makers more effectively and efficiently than 
current systems. 

C. SCOPE 

Due to time limitations, the research did not encompass the entire hospital 
operation. Therefore, after initial interviews and some detaUed study, one department 
was selected based on its high volume and overall impact on the hospital. The 
department chosen for the research was the Department of FamUy Practice and 
Community Medicine (DFPCM). The DFPCM is one of the 13 major departments 
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within SBHACH and serves nearly 53 percent of the hospital’s patients. An additional 
motivation for limiting the scope of the research was the increased depth of the 
analysis and design of an information system that would otherwise be possible. 

In addition to the direct study of the DFPCM, it was necessary to conduct 
research in the many supporting units which influence the department’s overall ability 
to function. The following support divisions were contacted during the course of 
research: 

• Resource Management Division 

• Information Management Division 

• Clinical Support Division 

• Department of Nursing 

• Logistics Division 

• Personnel Division 

• Patient Administration Division 

D. METHODS AND ORGANIZATION 

The thesis research followed the information systems development life cycle 
described in the first two sections of Chapter II. Chapter II discusses the theory of 
information systems and the analysis and design of such systems. The last section of 
Chapter II introduces the application of information systems to health care. Research 
was conducted to discover the history, current status, and future of hospital information 
systems (HISs) and the critical nature of these specialized systems. 

The DFPCM organization and functions are described in detail in the first section 
of Chapter III. Section 2 of Chapter III discusses the results of the current systems 
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analysis. Data Flow Diagrams (DFDs) are introduced in Chapter HI. DFDs 
diagrammatically portray the current information systems within the DFPCM. 

Chapter IV covers the requirements for improving the existing information 
systems within the DFPCM and how these improvements can be accomplished using 
an automated information management system. The findings in Chapter FV are a direct 
result of the analysis conducted in Chapter HI and described what is necessary for the 
information system to meet the needs of the department managers. 

The detailed systems requirements analysis is presented in Chapter V, 
incorporating the functional requirements and alternatives selected in the previous 
chapters. User Concept Diagrams (UCDs) are introduced in Chapter V to 

diagrammatically portray the proposed information systems for the DFPCM. The 
requirements analysis, as described in the chapter, is for the DFPCM alone. This 
analysis can be used to design and implement a management information system for 
this department, or with additional study, may be expandable to other clinics within the 
hospital. 

Conclusions and recommendations resulting from this thesis are given in Chapter 
VI. Chapter VI also suggests directions for further research work. 
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II. INFORMATION SYSTEMS 



A. INTRODUCTION 

This chapter introduces the concepts of an information system and the systems 
development process and discusses the impact of information systems within a hospital 
environment. 

Section B, System Design Concepts, describes the information systems 
development methodologies used in the thesis to design the information system for the 
Department of Family Practice and Community Medicine. The process of selecting the 
most appropriate system development methodology (ies) is also examined. 

Section C, Hospital Information Systems (HISs), describes the critical nature of 
the hospital organization and it’s impact on the role of information systems within the 
hospital environment, both historically and in the near fumre. Also presented in 
Section C is a description of the information systems currently used at SBHACH. 

B. SYSTEM'S DESIGN CONCEPTS 

An information system has been described as a collection of human, 
computerized, and mechanical agents that work together to acquire, produce, handle, 
store, use, and disseminate information (Lockeman, 1986, p. 617). Information systems 
are meant to support the day to day operations, management, and decision making 
needs of an organization. An effective information system does not necessarily have 
to be automated. Information systems exist, with or without automation, because 
workers within the organization require some sort of a system to collect, process, and 
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exchange the information they need. When automation is deemed necessary and 
properly designed, it can provide the organization with an increase in both the 
efficiency and effectiveness of operations. (Whitten, Bently, and Ho, 1986, p. 40) 

There are four important considerations in the development of an effective 
information system. First and foremost, the system must be designed to serve the 
needs of the users. The analyst has a responsibility to provide the user with a product 
that is both useful and correct. Secondly, the analyst should understand the 
organization’s mission to build the system to effectively support that mission. Thirdly, 
information systems provide one or more of the three information functions depicted 
in Table I. The analyst must determine which of these functions the system should 
support and how the information system will fit within the organization to fulfill those 
functions. Lastly, the system’s components, as depicted in Figure 1, should be 
designed to harmoniously work together to support the system’s intended purpose 
within the organization. (Whitten, Bently, and Ho, 1986, p. 692) This requires the 
analyst to systematically analyze the data inputs, data flows, processes, and information 
outputs. (Kendall and Kendall, 1988, p. 6) 

Table I. INFORMATION FUNCTIONS 

Data Processing Systems 

Processes large amounts of data for routine organization 

transactions. 

Management Information Systems 

Provides periodic reports for planning, control and decision making. 

Decision Support Systems 

Supports decision makers by providing information on demand. 
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• Computer equipment or Hardware. Information systems may include a variety of hardware 
components, including copiers, calculators, and computer systems. 

• Computer Programs or Software. A system Is a mixture of programs that either control the 
computer or provide applications to the users. 

• Users (Knowledge workers) are the most vital part of the Information system’s components. 

They are the central theme in any design methodology. 

• Methods and Procedures. Methods refer to how the system works whereas procedures 
describe how to perform the job and how to make decisions. 

• Data Storage. This is a fundamental component of the system. This Is the raw data that must 
be accessed to process into useful information, 

• Internal Controls. Feedback and control are system concepts that must be added to any 
system to ensure its proper operation. 

Figure 1. Information System Components (Whitten, Bently, and Ho, 1986, p. 692) 
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Prior to attempting the design of an information system, the systems analyst 
must choose a design methodology which wiU best meet his or her needs and the 
user’s needs. This selection process and a description of the methodology used in this 
thesis is described in the following sections. 

1. Systems Development Life Cycle Methodology 

System development in the late 1960s' was often behind schedule, over 
budget, expensive, and poorly suited to the users’ requirements. As a result, the early 
system designers developed a set of structured methodologies to make the development 
process more orderly and manageable. The emergence of structured methodologies 
provided the analyst with a welcome escape from the haphazard approaches used to 
develop the requirements, specifications, and programs used in the early design models 
(Ceri, 1982, p. 208). 

As the structured approaches became accepted as a viable systems design 
alternative, more analysts began to perceive that the structured methodology could even 
be further improved with the inclusion of a life cycle within the model. This enhanced 
structured approach, dubbed the Systems Development Life Cycle, was used by these 
analysts to bring together all of the already proven systems design techniques with the 
successful project management techniques. This system development life cycle 
methodology emerged as the most preferred method of all of the system design 
methodologies. (Wassermann, 1984, p. 44) 



This continues to be the case in the eighties. 



Figure 2 portrays the Systems Development Life Cycle methodology. This 
^proach provided several significant advantages over the non-strucmred approaches and 
the early forms of the structured methodologies. This design approach gave the systems 
analyst a better understanding of the user’s requirements while the increasing the user’s 
comprehension and participation in the design process. (Willis, Huston, and d’Ouville, 
1988, p. 56) Users also tended to be a lot more satisfied with the fiinal outcome of a 
system designed using this methodology. Information systems designed using this 
methodology were also found to be more flexible and maintainable then the early 
approaches. (Sumner and Sitek, 1986, p. 235) 

As Figure 2 shows, the life cycle begins with a project development request. 
Before a more detailed systems study is started, the systems analyst surveys the 
problem, opportunity, or directive that initiated the request. This survey is used to 
determine whether or not significant resources should be committed to the project. If 
the system development is approved, the development enters the first major phase of 
the SDLC, the study phase. The goal of the study phase is to educate the analyst about 
the current system, thus allowing the causes and effects of the problems to be 
discovered. This type of analysis is presented in Chapter IE of this thesis. 

The next phase, the requirements phase, is the most critical of the life cycle 
phases because it provides the foundation for aU subsequent phases (Willis, Huston, and 
d’Ouville, 1988, p. 56). This phase is concerned with the analyst understanding the 
problems found in the study phase and describing them in terms of the activities, data. 
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information flows, relationships, and system constraints necessary to solve the problem 
(Ceri, 1982, p. 205). This type of analysis is presented in Chapters IV and V of this 
thesis. 




Figure 2. Systems Development Life Cycle. 
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The evaluation phase looks at how the new system should be developed. The 
analyst must seek out all possible solutions to the problem and generate a set of 
alternative proposals to solve the problem. Each alternative is then evaluated on 
technical, operational, and economic feasibility. The outcome of this phase should be 
a technically feasible solution. (Whitten, Bendy, and Ho, 1986, p. 149) 

If this solution calls for new hardware or software, the selection phase 
becomes necessary. Ehiring the selection phase, the analyst determines which system 
specifications are important for the equipment or software required for the new system. 
Proposals are then developed and sent to vendors. Once the vendors’ proposals are 
returned, the systems analyst selects the hardware and software configurations that best 
meets the project’s needs at the most reasonable cost. (Whitten, Bendy, and Ho, 1986, 
p. 151) 

Given the user requirements, a feasible solution, and the hardware or 
software configurations from the selection phase, the analyst can now design and 
construct the information system. Computer outputs are normally designed first, 
followed by files/databases, and subsequently the user inputs and terminal dialogues. 
The design phase is where system controls, as implemented in methods and procedures, 
first enter the developmental life cycle. The deliverable of this phase is the completed 
design specification and the preliminary procedures necessary for the construction of 
the new system. The construction and design phases are frequendy the most time 
consuming and tedious phases, particularly if the requirements are incomplete or do not 
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reflect the actual user’s requirements. Finally the system is delivered, the users are 
trained, and the system enters the maintenance phase. (Whitten, Bently, and Ho, 1986, 
pp. 151-155) 

Throughout the various phases, the analyst is collecting facts, documenting 
the system, presenting ideas, and reevaluating the feasibility of the system. All of the 
phases of the system development life cycle are not discreet and distinct phases. Figure 
3 illustrates how each phase can overlap within the life cycle. (Whitten, Bently, and 
Ho, 1986, p. 157) As a life cycle model should indicate, the process will begin again 
as new project requests are generated, the organization evolves, or the system once 
again fails to meet the user’s requirements. 



Activity 
Survey the Situation 

Study the Current System 

Define User Requirements 

Evaluate Alternative Solutions 
Select New Computer 
Equipment and Software 

Design the New System 

Construct the New System 

Deliver the New System 




Week 



Figure 3. Overlap Opportunities within the Systems Development Life Cycle. (Wliitten, 
Bently, and Ho, 1986, p. 157) 

In spite of the large number of structured methodologies available, this type 
of systems analysis is not widely used (Sumner and Sitek, 1986, p. 235). Today, only 
about ten percent of the data processing organizations in North America practice 
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structured techniques in a disciplined fashion even though 90% of the community is 
at least superficially famUiar with the basic concepts (Yourdon, 1986, p. 133). 

Prior to selecting the use of one of these methodologies in our thesis, a 
closer look was taken to determine why these methodologies, so often taught at 
universities, were not being used. Yourdon explains that there are many reasons for this 
reversal in the attitudes toward structured analysis. He felt that the primary reason for 
this reversal was the frustration of analysts over the amount of manual labor required 
to develop systems using the stmctured methodologies. Analysts in a real business 
environment did not have the time to do the time consuming requirements 
documentation necessary for the requirements analysis when there was a large backlog 
of projects awaiting development. The analysts also became increasingly frustrated 
with the inability to apply these methodologies to complex, real-time systems. 
(Yourdon, 1986, p. 133) Additionally, many systems analysts were not trained in the 
use of the methodologies and tools and were unsure as to which tools could be 
effectively used within the phases of the life cycle (Ceri, 1982, p. 208). One of the 
major reasons for this reversal of attitudes was the development of the prototyping 
methodologies discussed in the following section. Many analysts were lured away 
from the structured approaches to systems development by the promise that prototyping 
could be used to interactively design and progressively tune the systems design without 
the rigorous requirements of the structured approaches (Ceri, 1982, p. 208). 

Too often, even though the stmctured techniques were used, the end result 
was a better design that still did not meet the users’ needs. Because of the time lag 
between the analysis and implementation phases in the stmctured methodology, the 
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users’ environment changed even after the system’s requirements were set in the 
requirements and design phases. The users also had difficulty communicating their 
requirements to the analyst. Senn points out "users can point to features they like or 
dislike in an existing system more easily than they can describe them in an imaginary 
or proposed system." (Senn, 1987, p. 611) These observations led to the conclusion 
that a better design methodology was needed to meet system development requirements. 

2. Prototyping Methodologies 

Information systems analysts saw the need for an improved design method. 
They felt that any systems development approach required the concurrent learning of 
both the analyst and the users. During the requirements phase, the major functions of 
the analyst are to help users formalize their tasks and decision processes, ensure that 
the users learn the analyst’s modeling techniques, and help the users understand the 
scope of the project (Cerveny, 1987, p.98). The structured methodologies simply did 
not fulfill this requirement. Recent developments in computer technology, primarily the 
introduction of user friendly code generators, allowed the systems analysts to develop 
a better approach to the systems development process. This new approach, prototyping, 
was designed to alleviate some of the problems that concerned the systems analysts 
about the traditional approaches. (Willis, Huston, and d’Ouville, 1988, p. 57) 

The concept of prototyping is not new. In engineering, prototyping has long 
been a standard for developing and testing new products and systems (Scharer, 1983, 
p. 60). Prototyping was not designed to replace the systems development life cycle. 
Instead, prototyping enhances the life cycle by promoting the mutual learning processes 
between the analyst and user (Cerveny, 1987, p. 98, 103). Prototyping uses the power 
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of demonstration to enable the user and the analyst to literally see their specification 
in action (Scharer, 1983, p. 60). Prototyping has the following significant advantages 
over the traditional structured methodologies: 

• Gets the user more actively involved in design and development. 

• Provides the user with a tangible means of comprehending and evaluating the 
proposed system. 

• Achieves more meaningful user feedback in terms of their needs and 
requirements. 

• Develops better relationships between systems analysts and user groups. 

• Results in fewer post implementation changes, resulting in lower maintenance 
costs. (Kroenke, 1987, p. 157) 

• The system that had been prototyped could be developed in one quarter of the 
time required of the structured methodologies. (Willis, Huston, and d’OuviUe, 
1988, p. 58) (Harrison, 1985) 

The main benefit of using a prototype methodology is the development of 
an information system that more closely fits the needs of the organization. Prototyping 
also reduces the risks involved with the development cycle by getting the system into 
operation quickly and keeping the system simple. (Cerveny, 1987, p.57) Prototyping 
is not superior to the traditional methods in all cases. Table II depicts the factors that 
favor either the traditional or prototype methodologies. 

Figure 4 depicts the modified systems development life cycle where 
prototyping techniques have been integrated into the life cycle. After the users have 
specified their needs, the analyst can then demonstrate how the proposed system can 
meet those needs. Design by prototyping consolidates the requirements definition, 
design, and construction stages of the typical system development life cycle discussed 
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earlier. These three activities take up approximately 60 percent of the manhours 
required for a system study. Consequendy, prototyping yields a net saving in effort 
when it is utilized in the design of information systems. (Willis, Huston, and d’Ouville, 
1988, p. 58) 

Table II. FACTORS FAVORING ALTERNATIVE DEVELOPMENT METHODS 
(Willis, Huston, and d’Ouville, 1988, p. 58) 

Project Characteristics of Alternative Development Methods 

Factors Favoring Traditional Systems Development 

• Data needs are clearly defined. 

• Systems have long life expectancy. 

• Tight controls are required. 

• Development risks are clearly defined. 

• Essential system features are known in advance. 

• Operational characteristics are well understood. 

Factors Favoring Prototyping 

• User requirements are uncertain. 

• Procedure changes are extensive. 

• User environment is volatile. 

• System has relatively short life expectancy. 

• System needs to be operational in short period of time. 

• Changes in specifications are anticipated. 

The constraction of a prototyp>e model requires that the systems analyst 

follow the six basic steps listed in Table HI and described below. 

Table III. STEPS IN PROTOTYPE DEVELOPMENT (Willis, Huston, and d’OuviUe, 
1988, p. 57) 



Prototyping Design Steps 

1. Select an appropriate application. 

2. Identify basic needs. 

3. Develop the working model. 

4. Refine the model and system interface characteristics. 

5. Implement revisions and enhancements. 

6. Prepare prototype documentation and plan for development. 
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Figure 4. Prototyping Systems Development Life Cycle 
a. Step One: Select Appropriate Application 

The first consideration for the systems analyst is to determine if the 
system under development favors the prototyping design methodology. This 
methodology is not superior to the structured approaches in all cases. The analy.st takes 
into consideration all the factors listed in Table II, Factors Favoring Alternative 
Development Methods, the user’s environment, and the availability of prototyping tools 
to determine if the system can best be developed with the prototyping approach. 
(Willis, Huston, and d’OuvUle, 1988, p. 58) 
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The environment within the DFPCM favored the use of prototyping for 
the following reasons: 

• Uncertain user requirements. 

• The environment was particularly unstable, subject to wide swings of p>ersonnel 
availability and work procedures. 

• The new system is needed immediately to meet the department’s expanding 
role within the hospital. 

• The system was expected to have a relatively short life cycle. 

• Numerous changes were expected in the specifications, as reports, procedures, 
and requirements for information appeared to be changing daily. 

b. Step Two: Identify Basic Needs 

The second step in prototyping involves getting a better understanding 
of the problem or opportunity that was developed in the study phase. (Willis, Huston, 
and d’OuviUe, 1988, p. 59) The goal of this step is to develop enough of an 
understanding of the problem to enable the design and construction of the initial 
prototype model (Boar, 1984, p. 67). 

c. Step Three: Develop Working Model 

The purpose of this step is to buUd the initial version of the prototype. 
Screens and documents layout are defined, data records are specified, and other model 
characteristics are established (WDlis, Huston, and d’OuvUle, 1988, p. 59). Content, 
not presentation, should be the primary goal of this initial model (Boar, 1984, p. 69) 
The analyst’s intent, in this stage, is not to come up with the perfect model but to 
develop a model that best matches the user’s view of the problem. Quality is critical. 
If the model is incomplete, it results in a poor foundation for the rest of the 
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development cycle. The target time for delivery of the initial model, depending on the 
prototype environment, should be three to six weeks. (Boar, 1984, p. 69) 

d. Step Four: Refine Model and System Interface Characteristics 

In this step, the system is refined so that each of the initial prototypes 
tested earlier are now required to woric together. The analyst’s goal in this step is to 
immediately test new ideas to see what refinements will satisfy the majority of the 
users. As users review this refined prototype and changes are made, the important 
changes are documented for later reference. (Willis, Huston, and d’OuviUe, 1988, p. 59) 

e. Step Five: Implement Revisions and Enhancements 

The objective of this step is to allow the users to review the 
information system in as complete a context as possible. This review occurs after all 
the changes and enhancements have been implemented and serves as the final 
evaluation of the information system in the eyes of the user. (Willis, Huston, and 
d’Ouville, 1988, p. 59) Except for minor problems, the prototype is essentially 
complete. 

/. Step Six: Prepare Prototype Documentation and Plan for 

Development 

This stage of the prototype cycle involves the completion of the 
documentation for the system and the determination of the fate of the prototype. The 
format and the extent of the documentation rests largely with the project manager. The 
final decision is made concerning how the prototype should be used in the new system. 
At this stage the analyst can go in three directions with the prototype. 
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• If the implementation of this prototype is too expensive or infeasible, the 
system can be abandoned. 

• Depending on the analyst’s prototyping development tools, the prototype could 
actually be implemented directly. 

• As is the case with this thesis, the prototype could be used simply as a step 
to another stage of the development process. The prototype provides the 
analyst with a knowledge base for the design of the new system. (WUlis, 
Huston, and d’OuviUe, 1988, p. 59) 

The successful prototype clearly enhances the traditional approaches. It 
is usually considerably cheaper, less risky, and conveniently keeps the system simple 
from the user’s perspective. It’s primary advantage is that it allows the user to see the 
application in its operational context and determine if the current design fits his or her 
needs. (Willis, Huston, and d’Ouville, 1988, p.60) 

C. HOSPITAL INFORMATION SYSTEMS (HIS) 

1. The Critical Nature of Hospital Information Systems 

The health care delivery system in a hospital environment is generally 
viewed as an industry. This industry has seen major changes in recent decades due to 
breakthroughs in medicine and technology. The cost of health care nationwide has 
increeised more than tenfold since 1950 to over $120 bUlion making health care one 
of this nation’s largest industries (Rakich and Darr, 1978, p. 1). In addition to the 
major changes taking place in the health care industry, the very nature of health care 
delivery creates a complex organization for the hospital administrator. Rakich and Darr 
suggest the hospital is one of the most complex organizations in existence based on the 
characteristics discussed below. 
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• There is a wide diversity of objectives and goals for different personnel and 
subsystems (e.g., patient care, education, research, accommodations, 
administration). 

• The diversity of personnel ranges from highly skilled physicians and 
administrators to unskilled laborers. 

• The hospital is in continual operation. 

• Hospitals deal with life and death decisions. 

• Measuring the major product (patient care) is difficult. (Rakich and Darr, 1978, 
p. 1) 

These often conflicting attributes can cause problems for hospital decision 
makers. A dichotomy is created by the conflicting goals of the hospital’s two 
components, management and operations, and becomes most evident and important in 
an environment where societal pressures and legal implications concerning ethical 
behavior are greatest. The non-medical management component (sometimes referred to 
as "bean counters") measures efficiency, i.e., the maximum amount of output (hospital 
services) for a given input (cost). The medical component (health care providers) 
measures performance by the quality of care provided to the patient (Longest, 1978, 
p. 125). This difference of purpose and objective will impact the manner in which 
information is managed and used in the hospital environment. Figure 5 is a humorous 
portrayal of the conflicts which exist between doctors and administrators when 
considering the use of computer resources (Cowey and McAlister, 1980, p. 141). 
However, the consequences of such conflicts are quite serious and play an important 
role in the potential effectiveness of a hospital information system (HIS). 

Another factor influencing the HIS is the complexity of the relationship 
between the doctor and the patient. The ethics and responsibilities involved make 
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doctors wary of new technologies and methods unless the benefits to the patients can 
be proven. (Safir, 1978, p. 98) 
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Figure 5. Conflicts 

The complexity and significance of health care organizations described in the 
preceding paragraphs creates a critical environment for a HIS. The conflicts which exist 
have affected the use and advancement of HISs throughout their life span and continue 
to influence the way in which hospital personnel view the quality and effectiveness of 
the ms. (Safir, 1978, p. 98) 

2. HIS Environmental Overview 

Early hospital information systems were developed primarily to support 
hospital administration. Hospitals applied computer resources in conventional ways for 
accounting and other business related administration. Computers were also used in 
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medical research but were not generally considered suitable for directly supporting the 
medical care given to patients. 

Figure 6 (Cowey and McAlister, 1980, p. 137) shows three main areas 
where medical computing can be applied in a hospital environment. The two large 
circles represent the more traditional applications of computers in health care, 
administration and research. The intersection of these circles represents the area of 
medical computing related to the care provided to patients. This area overlaps both 
medical research computing and administrative computing and is affected by the 
conflicting objectives of doctors and managers discussed earlier. We targeted this area 
of medical computing in our research and found a tremendous lag in the computer 
technology applied to medical care delivery. 




Figure 6. Three Areas of Medical Computing 
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Experts in both the medical and computer fields began to recognize the 
medical computing lag in the mid-1970s and have made concerted efforts to catch up. 
A Symposium on Computer Applications in Medical Care (SCAMC) has met annually 
since 1976. In 1978, hearings were held before the Subcommittee on Domestic and 
International Scientific Planning, Analysis and Cooperation to discuss the topic of 
computers in health care. The reasons for the medical computing lag can be traced 
back to the critical nature of the HIS introduced in the previous section. In 1978, 
Aran Safir M.D. wrote: 

...the complexity that characterizes human interactions is perhaps nowhere better 
demonstrated than in the relationship of doctor and patient. Representing such 
complex human interactions effectively within the computer is exceedingly 
difficult. (Safir, 1978, p. 98). 

In 1980, Cowey and McAlister found it was rare for hospitals to devote a 
portion of its budget to data processing equivalent to that spent by most other 
industries of comparable size (Cowey and McAlister, 1980, p. vi). The following 
barriers to medical computing were suggested in 1985 by Bonnie Kaplan, Ph.D. at the 
annual SCAMC symposium (Kaplan, 1985, p. 400): 

• Lack of funding, technology, staffing, training, and effort. 

• Poor management including difficulties of interdisciplinary teams, planning and 
approach, and lack of attention to human factors and methodologies. 

• Difficulty of translating medical knowledge into a form suitable for computing. 

• Institutional constraints and physician resistance. 

These barriers will exist to some degree in every organization. Many 
hospitals are attempting to hurdle the barriers through improved communication and 
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cooperation between doctors and administrators. Large hospitals are moving toward a 
HIS which integrates administrative, research, and medical service computing into one 
complete system. An example of an integrated HIS is the University Hospital 
Information System (UHIS), introduced in 1980 when the University Hospital at State 
University of New York first opened its doors. UHIS offered a wide range of patient 
care services including registration, medical records, automated lab data, quality control, 
jrfiarmacy, radiology and nursing (Vegoda and Dyro, 1986, p. 261). 

The medical computing future shows a trend toward increased integration of 
hospital information system functions like that described in the UHIS. The Yale-New 
Haven Hospital began implementing the Patient Care Support System (PCSS) in 1986. 
PCSS is expected to take several years to implement. When complete, PCSS is 
expected to improve the quality of care rendered to patients by allowing physicians to 
more efficiently and accurately order tests, lab work, and prescriptions. Medical record 
tracking and results reporting is also expected to improve (Sadock, 1986, p. 114). 

The Department of Defense’s answer to an integrated HIS is the Composite 
Health Care System (CHCS) scheduled for completion in 1991. The objectives for 
CHCS include: "improving the quality of patient care, increasing the efficiency of 
operations, increasing the accuracy and availability of information, and providing 
standardized, but flexible support." (Regional Training Conference Manual, 1988, p. 
135). In 1988, a Regional Training Conference was held in Monterey, CA to update 
attending medical professionals on military and other government medical information 
system initiatives (Regional Training Conference Manual, 1988). One of the topics 
covered at the conference was the planned implementation of CHCS. The following 
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patient care benefits of the CHCS were cited (Regional Training Conference Manual, 
1988, p. 140): 

• Improved quality of care. 

• Reduced time spent handling information. 

• Improved management control of operations. 

• Increased patient satisfaction. 

• Increased compliance with standards and regulations. 

• Increased service capacity with same staff levels. 

• Improved personnel morale and job satisfaction. 

Doctors and hospital administrators are trying to recover from the medical 
computing lag which has continually plagued the industry. They are beginning to 
realize the importance of quality information for providing high quality patient care. 
Integrated HISs are the future for medical computing and, if properly used, will enable 
the health care industry to provide better quality medical care. 

3. Information Technology at Silas B. Hays Army Community Hospital 
The current information technology at Silas B. Hays Hospital consists of 
three major systems, the Medical Expense and Performance Reporting System 
(MEPRS), the Automated Quality of Care Evaluation Support System (AQCESS), and 
the Computer Stored Ambulatory Record System (COSTARS). These three systems are 
completely independent and are maintained through separate government contracts. No 
attempt has been made to link these information systems into one large database. 
Because of the inherent incompatibility of the systems and the eminent arrival of the 
Composite Health Care System, SBHACH administrators believe it would be cost 
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prohibitive to attempt systems integration at this time. The next three sections describe 
the basic function of each of these systems, 
a. MEPRS 

The purpose of MEPRS is to collect, process, and report to the Health 
Services Command (HSC) all data on the medical workload, staffing, and expenses 
incurred by each workcenter within the hospital (Regional Training Conference, 1988, 
p. 47). Each hospital department maintains various worksheets to record manpower 
utilization and workcenter expenses. Each department reports the hours for clinicians 
(doctors) and non-clinicians (all others) to the MEPRS section, a subdivision of the 
Resource Management Division (RMD). Also recorded are the inpatient bed days and 
the number of outpatient visits for each of the workcenters. This workload information 
is maintained in both the AQCESS and COSTARS systems but because the systems 
are incompatible, the data must be manually extracted from each of the systems for 
entry into the MEPRS system. Direct expense data on such items as electricity and 
water is received from the Fort Ord Finance and Accounting Office and manually 
extracted by the MEPRS personnel and recalculated based on the square footage of 
each departments’ assigned space. This expense Information is then manually entered 
into the MEPRS computer. Each month all hospital data is loaded onto a magnetic 
tape and sent to the Health Services Command (HSC) at Fort Sam Houston, Texas. 
The data is used by the HSC for determining funding allotments for Silas B. Hays. 
The information maintained in the MEPRS system is not considered useful to the 
department managers because it is not kept in a format consistent with department 
resource measures. 
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b. AQCESS 



AQCESS was introduced early in 1986 for all Department of Defense 
Hospitals. The primary purpose of the system was to provide a standardized method 
for the collection and reporting of patient and provider information and to assist in 
quality assurance decision making for all military hospitals. AQCESS was intended to 
improve the quality of the information provided to administrators, doctors, and quality 
assurance personnel and to save hospital staff time. Initially implemented with three 
main modules, AQCESS has since been expanded to six modules. AH six modules are 
in operation at SUas B. Hays: 

1. Quality Assurance Module 

2. Appointment and Scheduling Module 

3. Medical Services Accounts Module 

4. Clinical Records Module 

5. Registration Module 

6. Emergency Services Module 

The Appointment and Scheduling Module affects each individual 
department the most as it determines the daily workload for each doctor in the 
department. 

The AQCESS system is used to capacity. Although ad hoc reports can 
be obtained by the users of AQCESS, only the system manager in the Information 
Management Division (IMD) currently uses this function. The system is heavily used 
during normal working hours for interactive appointment scheduling and clinical 
records. To help keep system response time low during the day, all AQCESS reports 
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are generated at night using batch processing. The AQCESS modules produce many 
reports which show hospital operations and performance in many areas. Statistical 
reports on workload, productivity, and appointment scheduling histories are just a few 
of the topics covered. 

c. COSTARS 

The COSTAR System is unique to the Family Practice Clinic at Silas 
B. Hays Hospital. This system receives, records, and retrieves administrative and 
medical information for the active duty families enrolled in the Family Practice 
Program (Libra Technology, 1982, p. 2). This system was actually a prototype system 
introduced in 1982 and initially had the five main functions described below: 

• Registration - This function allows patients to be enrolled in the Family 
Practice Program. 

• Appointment and Scheduling - This function allows the COSTARS data entry 
clerk to book, cancel, or view appointments. It also prints daily schedules and 
appointment lists and produces a pull list for the medical records department 
indicating which patients records will be required for the following day’s 
appointments. 

• Medical Records - This functions maintains a history of a patient examination, 
including administrative, physical, diagnostic and procedural data. 

• Pharmacy Orders - This function was intended to provide full pharmacy 
support by allowing prescription orders to be automatically forwarded to the 
pharmacy. Records on pharmaceutical history were also to be kept for the 
patients. Currently, only prescription refills are managed by this system. 

• Laboratory Orders - This function permits physician orders for lab work to 
be automatically sent to the lab before the patient arrives. Results are also 
entered and a daily report is sent to the physician showing the patient and the 
results of the lab tests ordered for that patient. 

Like AQCESS, the COSTARS system maintains a large data base and 
is capable of producing many reports. COSTARS also accepts ad hoc queries but none 
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are currently being used. The pharmacy and laboratory functions offer capabilities not 
found in AQCESS. As with the other major systems, we believe this system is not 
being exploited to full advantage. This system, and the potential benefits of the data 
maintained within it, are discussed further in subsequent chapters. 

In addition to the three major information systems discussed above, 
Silas B. Hays makes extensive use of microcomputers for office automation and 
individual data processing functions. These computers are not currently networked nor 
is there any standardization of software or procedures. 

The current information systems available at Silas B. Hays Hospital 
are cumbersome and cannot be integrated to provided timely, reliable, and useful 
information to hospital decision makers. The lack of integration is seen as a major 
problem by many hospital personnel and, until the CHCS comes on line, stop-gap 
measures are being used to fill the void and provide the best information available 
with the limited resources. 

The remainder of this thesis describes how one department, the 
Department of Family Practice and Community Medicine (DFPCM), uses the current 
information systems available at SBHACH. Also examined is the need for an improved 
system and how these improvements might be realized through the use of a responsive 
microcomputer-based information system. 
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III. CURRENT SYSTEMS ANALYSIS 



A. INTRODUCTION 

Chapter II introduced information systems development methodologies and the 
application of information systems within a hospital environment. This chapter 
describes the current information systems in the Department of Family Practice and 
Community Medicine, using the development principles discussed in Chapter II. This 
chapter introduces data flow diagrams as a pictorial way to represent the existing 
information system and presents data flow diagrams and narrative descriptions for the 
department’s information system. 

B. THE DEPARTMENT OF FAMILY PRACTICE AND COMMUNITY 
MEDICINE 

Early in 1988, Health Services Command approved a reorganization for SUas B. 
Hays Hospital which combined the Department of Family Practice with the Department 
of Primary Care and Community Medicine, creating the Department of Family Practice 
and Community Medicine (DFPCM). This new department is the hospitals largest and 
most diverse in terms of both the services it provides and it’s overall affect on the 
hospital. Figure 7 is the department’s organization chart. The department has three 
general service areas: Family Practice and Residency, Primary Care, and Consolidated 
Troop and Family Member Services. These are further divided into specialized clinics 
(sometimes referred to as sections) as shown in the chart. All of these clinics are 
outpatient oriented and are literally the gateways to all other hospital services (e.g.. 
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Figure 7. Organizational Chart for DFPCM 

pharmacy, lab, and specialized medical departments). The DFPCM affects every aspect 
of the hospital: every patient treated at Silas B. Hays must first be seen by a doctor 
working in one of the DFPCM clinics. The mission of the DFPCM, as stated in the 
Health Services Command Regulation 10-1, is "to provide diagnosis, care, and treatment 
of all patients commensurate with the highest standards of quality." (HSC Reg 10-1, 
1987, p. 3-1) The task of accomplishing this mission is not nearly as simple as the 
mission statement itself. 

The size of the department, the volume of work done, and the impact on overall 
hospital resources combine to create a highly visible, management challenge. The 
Chief of the DFPCM (currently a Lieutenant Colonel) is responsible for meeting this 
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challenge. The resources he commands include over 150 people and an annual budget 
of nearly half a million dollars. In addition, there are five separate service locations, 
one of which is 100 miles from the main hospital (Fort Hunter Liggett). Unfortunately, 
these resources are limited compared with the task at hand. Since his time is 
extremely valuable, the information he gets should be summary in nature in order that 
he not be overwhelmed with meaningless data, and yet at the same time, complete 
enough to allow him to make informed, confident decisions. All of these factors must 
be considered when designing an information system for use by the Chief of the 
DFPCM. 

Initial interviews with the Department Chief allowed us to identify those 
management areas which demand the greatest attention and for which he requires the 
best possible information. These areas fell into the following seven broad categories: 

• Fiscal Resources. 

• Material Resources. 

• Personnel and Scheduling. 

• Productivity. 

• Patient Satisfaction. 

• Medical Procedure Suspense Information. 

• Patient Check-In and Records Procedures. 

The last two areas were determined to be beyond the scope of this thesis because 
of time constraints and the inherent size and complexity of the projects themselves. 
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The Department Chief agreed with our decision and prioritized the remaining five areas 
as shown below: 

• Fiscal Resources. 

• Material Resources. 

• Personnel and Scheduling. 

• Patient Satisfaction. 

• Productivity. 

The remainder of this thesis describes the research into each of these areas and the 
requirements for an information system which would serve the Department Chief in 
making management decisions concerning these key areas. 

The five major areas listed above were divided into the following six specific 
systems: 

• Budget System. 

• Equipment System. 

• Personnel System. 

• Scheduling System. 

• Patient Satisfaction System. 

• Productivity System. 

The following section describes the six existing information systems listed above 
(with diagrams and written narrative) and how information is gathered, stored, and 
presented for decision making. As described in Chapter II, the current system should 
be well understood before any attempt is made to improve any part of it. Subsequent 
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chapters discuss where and why improvements are needed and how those improvements 
can be achieved through system redesign and automation. 

C. DATA FLOW DIAGRAMS 

In the preliminary description of the information system within the DFPCM, we 
used Data Flow Diagrams (DFDs) to represent the current system to department 
personnel. The Data Row Diagram enables the designer to describe the existing 
system or the proposed new system at a logical level without considering the physical 
environment in which the data flows (e.g., telephone calls, maU, etc.) or the physical 
environment in which the data is stored (e.g., card file, microfiche, disk, floppy disk, 
or tape). (Atkas, 1987, p. 57) The DFD describes the system as a network of 
processes (subsystems) connected to each other and/or to data stores, sources and sinks. 
(Atkas, 1987, p. 58) The basic symbols used in the DFD’s are described below. 

• Data Flow. An arrow is used to represent either the flow of information or 
objects. Occurrences of the data flow must contain data. 

• Process. A rounded rectangle represents a process. Processes are work 
performed by people, machines, or computers on incoming data flows to 
produce outgoing data flows. (Whitten, Bently, and Ho, 1986, p. 226) 

• External Entity or Boundary. A square is used to represent an area in 
which data originates or terminates. In essence, the sources and sinks define 
the boundaries of the system. 

• Data Store. An open-ended rectangle represents a store of information or 
objects, irrespective of the storage medium. (Atkas, 1987, p. 59) 
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The components of the information system correspond to the DFD symbols as follows 
(Whitten, Bendy, and Ho, 1986, p. 234): 



Information System Component DFD Symbol 



Data (Input) 



Data Flow 



Information (Output) 



Data Flow Users 



Entity/Process 



Methods/Procedures 



Process Data Storage 



Data Store 



Computer Equipment 



Process/Data Store 



Computer Programs 



Process 



To achieve clarity, DFD’s are prepared at several levels. The highest level DFD 



study. The processes are further decomposed as necessary into lower level diagrams. 
(Atkas, 1987, p. 68). The following sections use DFD’s to illustrate the six current 
information systems. 

1. Budget System (see DFD, Figtire 8). 

The Resource Management Division (RMD) receives the hospital’s budget 
from the Health Services Command on an annual basis via the MED 304 report. 
RMD divides this budget into quarterly budget targets for each department and 
distributes the budget allocations at the beginning of each quarter. The department 
Non-commissioned Officer in Charge (NCOIC) (currently a Master Sergeant) is the 
principle administrator of all incoming budgetary information. He serves both as the 
Department Chief’s budget administrator and the clinics central point of contact on all 



is the "context diagram," which merely shows the boundaries of the system under 
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budgetary matters. This practice of using the NCOIC as the monitor appears to be 
common practice throughout the hospital. 

Once the department’s budget is received from RMD it is allocated by the 
NCOIC into 16 separate accounts. The 16 budget accounts reflect the current 
organizational structure with a few exceptions required by funding needs. The 16 
sections are listed below: 

• Primary Care. This is an overall budget category for any department wide 
requirements. 

• Family Practice Clinic. This is the eighth floor Family Practice clinic at the 
hospital. 

• CTMC-Family Practice. This is the Family Practice clinic operated at the 
CTMC. 

• Emergency Medical Services. This is the emergency room excluding the 
ambulance section requirements. 

• Ambulance Section. Supply budget for the ambulance section which is a 
subsection of the emergency room. 

• Flight Surgeon Office. 

• General Outpatient Clinic. Serves walk-in patients and active duty sick call 
in the Hospital. 

• Presidio of Monterey-Health Clinic. Though the POM clinic is run by 
PRIMUS, the department assigns a doctor as liaison to handle sickcall and 
official military matters for which it receives department funds. 

• Consolidated Troop Medical Clinic (CTMC). Medical care for 7th Light 
Infantry Division personnel. 

• Battalion Aid Station. This money is provided to the Division Medical 
Supply Office to reimburse medical supplies used by the battalion aid stations 
throughout the division. 

• Fort Hunter Liggett Clinic. 
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• CTMC (Pathology). Funds in this category pay for supplies needed by the 
pathology section located at the CT^iC. 

• CTMC (Radiology). Funds in this category pay for supplies needed by the 
X-Ray section at the CTMC. 

• CTMC (Pharmacy). Funds in this category pay for supplies needed by the 
Pharmacy Section at the CTMC. 

• CTMC (Immunization). Funds in this category pay for immunization 
supplies for the CTMC. 

• Battalion Aid Station (Immunization). Funds in this category pay for 
immunization supplies used by the battalion aid stations. 

Each section prepares requisitions and monitors its expenditures in its own 
Document Control/Funds Control register (DC/FC). This document serves as a record 
for items ordered and an indicator of the account’s remaining funds once the supplies 
are received. The DC/FC register is currently maintained manually in each clinic’s 
supply section. One important location for the expenditure of supply dollars is the Self 
Service Supply Center (SSSC). The SSSC is a self service supply point for certain 
office, medical and computer supplies. These supplies are charged against the 
individual section’s account and are usually recorded on a weekly recap basis by an 
entry into the DC/FC register. These expenditures are reconciled on a weekly basis 
with the Detailed Obligation Report (DOR). This report confirms correct obligation 
amounts and recorded orders. Four copies of the DOR are received weekly from RMD 
in microfiche form. The four copies are distributed to the CTN'IC, Fort Hunter Liggett 
clinic, the main Family Practice clinic, and the department NCOTC. There are a 
limited amount of DOR’s available, so every section cannot receive it’s own copy. 
This shortage is caused by a number of microfiches actually delivered to RMD. 
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Figure 8. Budget System Data Flow Diagram 



The NCOIC provides the Department Chief with budget information via 
the department Budget Status Report (see Figure 9). This report is prepared at the 



beginning of the quarter, at the beginning of each month, and on a recap basis at the 



end of each quarter and the Fiscal Year. The Budget Status Report is the department’s 
principle source of information on current budget and expenditure status for each of 
the 16 accounts. The report is currently generated using a LOTOS 1-2-3 spreadsheet 
program maintained by the NCOIC. The spreadsheet printout shows expenditures by 
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Figure 9 
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DEPT TOTALS 124200 1566.79 40962.49 42529.20 42529.28 01670.72 41400 1.03 -0.03 0.34 0.66 



section, their uncommitted funds and appropriate percentages of expenditures for the 
reporting period. The printout is given to the Chief monthly and maintained by the 
NCOIC in a file on a microcomputer disk. 

Monthly, the NCOIC receives a month-end report from RMD that reflects 
the expenditures by medical and non-medical categories for each of his separate clinics. 
TTie month-end report is used to update the Budget Status Report for review by the 
Department Chief and the section chiefs. The principle problem with this system 
concerns the end of year constraints. As the end of the year approaches, the 
expenditure of funds becomes crucial. The amount that is reflected in the month-end 
report may be several obligations behind the actual expenditures recorded in the 
section’s DC/FC register. This requires a direct matching of available funds by 
monitoring the sections through telephonic expenditure reports. 

Quarterly, the Resource Information Report is generated to be used in a 
meeting between the Department Chief and his section chiefs (see Figure 10). This 
report serves as the agenda for the meeting. The primary topic in this meeting is the 
projected budget shortfalls for the quarter based on unforeseen requirements. 

On an as needed basis, the Budget and Equipment Analysis and Review 
report (the BEAR) is requested from the section chiefs. This report reflects much the 
same budget information contained in the Resource Information Report but includes 
important information on the status of critical department equipment such as 
replacement or maintenance requirements (discussed below). Tlie BEAR is collected 
by the NCOIC for comments and delivered to the Chief for his review. 
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Figure 10. 



Resource Information Report (RER) 




IN 
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2. Equipment Procurement System (see DFD, Figure 11). 

The equipment requirements for the department are interrelated with the 
budget system described above in that all expenditures for equipment must be budgeted 
and tracked within that system. The department’s equipment needs occur in the four 
areas listed below; 

• Durable Equipment. This includes low cost, less than $1000, equipment that 
is used on a day to day basis. This equipment is funded through the normal 
supply budget. 

• Capital Expense Equipment Program (CEEP). Medical equipment that 
costs more than $1000 but less than $5000. The budget for this equipment 
is maintained by RMD. 

• Medical Care Support Equipment (MEDCASE). Equipment that costs more 
than $5000. This budget is maintained by RMD. 

• Computer/Electronic Equipment. Although the cost of this equipment is 
taken out of the department’s budget, the approval to order it comes from 
outside the department (discussed below). 

The primary source of equipment authorizations is the Table of Distribution and 
Allowances (TDA) which shows the equipment authorized to be procured and held by 
each department section. Special medical equipment not included in the TDA must be 
specifically identified and requested by the department. 

Each section identify their equipment requirements by determining equipment 
authorization levels, the equipment currently on hand, the status of equipment on order, 
and the equipment that requires replacement. The sections have numerous sources they 
can use to determine the status of their equipment. The T.ogistics Division’s Property 
Management Branch maintains property records for all equipment held by each section. 
They also produce reports on the status of equipment on order, the useful life of 
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equipment on hand, and the number of years the equipment has been extended over its 
defined useful life. The Medical Maintenance Division maintains cumulative status 
reports on the maintenance performed on all medical equipment along with the one- 
time expenditure limit which defines the maximum limit for future repair costs for each 
equipment item. This information is critical in determining if a piece of equipment has 
exceeded its allowed maintenance expense. 

The problem with all of these reports is their relative inaccessibility to the 
sections. The reports are not distributed to the sections and the maintenance reports 
are maintained in the Medical Maintenance building, separate from the ho.spital. 
Because of these difficulties, not all .sections attempt to obtain this information. 
Another major factor affecting the availability of this information is that the reports are 
not divided into sections or departments but maintained on a hospital-wide basis. 

Often, equipment needs are not identified until failure of the old equipment. 
The Department Chief and NCOIC recently created the Budget and Equipment Analysis 
Report (BEAR) to help them plan for equipment expenditures and better manage their 
equipment budget (see Figure 12). This report will be completed by each section on 
an annual basis to identify critical equipment needs. The BEAR report not only 
identifies critical needs but was intended to promote interest in identifying those needs 
in a more timely manner. The sections must identify their replacement requirements 
for the upcoming fiscal year and for four subsequent years, he sections also report the 
requirements for CEEP and MEDCASE items, along with the status of equipment on 
order. 
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Figure 11. Equipment System Data Flow Diagram 



Once the section’s requirements are identified with the BEAR, the 
Department Chief, in conjunction with his service chiefs, determines the priorities for 
the department. The appropriate paperwork is completed and forwarded to the RMD 
Logistics Division to await the next hospital wide Program and Budgeting Advisory 
Committee (PBAC). The PBAC consists of key hospital personnel who review and 
prioritize MEDCASE and CEEP requirements for each department. If approved, these 
items go onto a list of prioritized and approved equipment, either MEDCASE or CEEP, 
and await the availability of funds. 
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Figure 12. Budget and Equipment Analysis Report (BEAR) 
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Currently, there is no consolidated list of the department’s needs but each 
section maintains its own list. Tlie only source of consolidated information on 
equipment needs are the quarterly Resource Information Reports, discussed in the 
previous section. 

Needs for electronic and communications equipment are separately identified 
by each section on an Information Capability Request (CAPR). Once the CAPRs are 
approved by the Department Chief, they must be countersigned by the Chief, 
Information Management Division, the Deputy Commander for Clinical Services, and 
eventually by the Directorate of Information Management for Fort Ord (DOIM). Once 
approved, it is the responsibility of the department to obtain the funds and order the 
equipment. 

The Department Chief needs all of this information to plan for equipment 
expenditures. He can use the information provided by his sections to plead his case 
to the hospital administrators who allocate the funding dollars for his department. The 
"out year" information provides him with a projection of future equipment needs and 
helps improve the department budgets. 

3. Personnel System (see DFDs, Figures 13 and 14) 

The DFPCM employs more than 150 people. To effectively manage these 
people, the Department Chief requires personnel information in three main areas: 
authorized positions and vacancies, educational travel funding requirements, and 
personnel leave and temporary duty requests. 



47 



Each department in the hospital is authorized a certain number of people, 
by position, based on the Table of Distribution and Allowances (TDA). Tlie 
Department NCOIC uses a word processing program to keep a list of all authorized 
positions, both filled and vacant, for the DFPCM. This list contains appropriate TDA 
line numbers and position descriptions plus the personal data for all assigned persons 
(or a "vacant" indication if the position is unfilled). On an as-needed basis, the 
NCOIC prints the personnel position list for each section. Each section NCOIC, if 
necessary, updates his list and returns it to the Department NCOIC who then updates 
the master roster. The updated master roster is forwarded to the Department Chief and 
is also sent to the MEPRS section to update their Position Control Roster. 




Figure 13. Personnel System Data Flow Diagram 
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The Continuing Medical Education (CME) program provides the doctors 
within the hospital the necessary funds for continuing their medical education. Each 
doctor determines his or her educational needs and prepares a CME request which 



includes the estimated cost of travel. These requests are reconciled with the 
department’s allocated CME funds and if sufficient funds are available, the request is 
approved by the Department Chief and forwarded to the Deputy Commander for 
Clinical Support (DCCS) for approval. TTie DCCS publishes a master list of doctors 
approved for CME travel. The NCOIC requires each doctor who has completed his 
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or her CME travel to provide a copy of the travel claim voucher. Through this 
information, the NCOIC can capture actual CME costs well before they are reported 
by the travel personnel at finance (which can be one to three months after the travel). 
The CME funds are managed closely because actual costs often exceed the estimates 
originally stated in the request. The CME funds are maintained separately from supply 
funds. 

The Department Chief expressed a desire to monitor leave and temporary 
duty (TDY) status. Leave and TDY information is collected in two separate methods 
depending on the person involved (see Figure 14). Doctors send leave and TDY 
requests to the Department Chief, via their chain of command. Requests approved by 
the Chief are recorded in a journal kept by the department administration section and 
forwarded to the DCCS. The doctor must also notify the Assistant Department Chief 
(ADC) of any planned absences for scheduling purposes (see Figure 9, Scheduling). 
The hospital Personnel Administration Center (PAC) types approved requests on a 
Department of the Army (DA) Form 31. This form is routed through the hospital 
distribution system to the NCOIC who distributes it to the doctor’s respective section. 
Other personnel leave and TDY requests are routed through the Medical Company 
chain of command. After approval by the Medical Company First Sergeant and 
Commander, these requests are forwarded to the PAC, typed on a DA Form 31, and 
distributed via the department NCOIC to the appropriate section. 

The Department Chief’s main concern in managing personnel is planning for 
position vacancies and temporary absences due to leave and TDY. Presently, section 
chiefs report upcoming losses on an exception basis only, primarily when the position 
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involved is critical to section operations. The PAC has the capability to report military 
personnel losses on a 30, 60, 90, 120, 150, 180, 270, and 300 day basis, but this 
information is available only on a hospital-wide basis. 

4, Scheduling System (see DFDs, Figures 15 and 16) 

The Department Chief’s primary concern for scheduling lies in two clinics, 
the Family Practice clinic and the CTMC/FP clinic. Figures 15 and 16 show the 
doctor scheduling process as it currently exists in each of these clinics, respectively. 
a. Family Practice Scheduling 

The Family Practice scheduling system involves two primary schedules, 
the On-Call Schedule and the Clinic Schedule, and a secondary schedule, the Walk-In 
Schedule. TTie Assistant Department Chief (ADC) creates each of these schedules. 
This process is very subjective and difficult to define precisely. Each of the following 
sections describes the process for each of the schedules discussed above. 

(1) On-Call Schedule. The On-Call Schedule establishes which doctor 
will be on-call for each night of the month. The On-Call Schedule affects every clinic 
within the department except the Emergency Medical Services which have their own 
on-call schedule. To create this schedule, the Assistant Department Chief (ADC) 
maintains several different fUes which help him determine which doctor to schedule for 
each day. 

Every clinic has a minimum number of doctors which are required 
to be on duty each day. This information is maintained on a sheet of paper in the 
ADC’s scheduling folder and is necessary for creating the On-Call Schedule because 
a doctor who is on-call one day will not be available for duty the following day. The 
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ADC also maintains historical data for each doctor showing the number of times the 
doctor has been on call on holidays and weekends. The ADC keeps 3" x 5" cards 
with special requirements for each doctor such as continuing education, or conference 
dates for which the doctor would be unavailable for on-call duty. The doctors must 
also inform the ADC when they are requesting leave or when they will be away on 
temporary duty (TDY). The last information kept by the ADC is a cumulative 
monthly tally of the number of times each doctor has stood on-call duty for the last 
calendar year. After considering all of this information, the ADC creates the On-Call 
Schedule in a manner which will be fair to all of the doctors and yet fill the 
requirements for on-call duty and the following day’s clinic schedule. The on-call 
schedule is distributed to each doctor, the patient care nursing stations on each ward, 
the emergency room, and the Clinical Support Division. In addition, the on-call 
schedule is used to create the clinic schedule for the Family Practice doctors. 

(2) Clinic and Walk-In Schedules. As with the on-call schedule, the 
clinic schedule is created by the ADC after considering all of the information relating 
to doctor availability. Staff doctors have a permanent clinic schedule for each month. 
This is affected only by leave requests and TDY orders from the doctors themselves. 
The ADC must also schedule residents-in-training for clinic duty. Each resident is 
assigned a primary location for each month by the Resident Director. The ADC keeps 
this information in his scheduling folder along with special instnictions for each 
resident from his assigned clinic. TTiese instnictions, on 3" x 5" cards, contain 
information on the daily availability of the resident for duty in the Family Practice 
clinic. Also affecting the clinic schedule is the previous day’s on-call schedule: the 
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doctor who was on call the previous day will not be available for work in the clinic 
on the day in question. The ADC creates the clinic schedule based on the number of 
doctors available for each day of the month. The final clinic schedule is submitted to 
the COSTARS data entry clerk so the appointment system can be updated to show 
which doctors will be available to see patients in the scheduled month. Also, for each 
day on the clinic schedule, the ADC schedules one doctor to see walk-in patients. 
This doctor is then responsible, on the day assigned, to see all famUy practice patients 
who could not get an appointment but required immediate care. The walk-in schedule 
is attached to the final clinic schedule and distributed to each doctor. 




Figure 15. Family Practice Scheduling Data Flow Diagram 
b. CTMC/FP Clinic Schedule 

The Chief of the CTMC/FP clinic completes his clinic schedule in 
much the same manner as described for the family practice clinic. The on-call 
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schedule created by the ADC includes CTMC/FP doctors and therefore impacts the 
CTMC/FP daily clinic schedule. The Chief of CTMC/FP uses the previous day’s on- 
call schedule to determine which doctor will not be available for duty on the current 
day. Additionally, he receives each of the CTMC/FP doctors leave and TDY requests 
and special availability requirements which he maintains in one log book. He consults 
this log book and the on-call schedule for the upcoming month to create the CTMC/FP 
schedule for that month. He distributes this schedule to each doctor and one copy is 
sent to the AQCESS data entry clerk who updates the appointment scheduling database 
to reflect the doctors available for appointments in the CTMC/FP clinic for the 
upcoming month. 

As can be seen from the previous discussion, the scheduling process 
is subjective and dependent on the historical files and log books maintained by the 
clinic schedulers. The most difficult part of this process is obtaining and coordinating 
all of the information sources which affects the doctors’ availability for duty on any 
given day of the month. The ADC estimated that it required 3 to 4 hours to create 
the monthly schedules because of the many factors influencing the entire process. 
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Figure 16. CTTvIC/FP Scheduling Data Flow Diagram 
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5, Patient Satisfaction (see DFO. Figure 17) 

Determining patient satisfaction is a subjective process and is currently 
performed by the department’s quality assurance representative. The QA representative 
created a questionnaire to obtain subjective responses from patients on various topics. 
The patients are asked to respond "Yes", "No", or "Not Applicable" to eleven questions 
concerning the care they received in the Family Practice clinic. This is the only clinic 
currently using the patient satisfaction survey. 




Figure 17, Patient Satisfaction Data Flow Diagram 

On one day of each month, the doctors in the FP clinic are asked to 



distribute the questionnaires to the patients they see, with instructions that the patient 



return the surveys to the receptionist at the nurses station. The receptionist gives all 
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of the collected surveys to the QA representative who then calculates the percentage 
responses for each of the questions and produces Monitor and Evaluation Reports. 

Each Monitor and Evaluation (M&E) report prepared by the department 
QA representative represents an important aspect of care recognized by the hospital QA 
Division (see example, Figure 18). Each question in the survey is an indicator of one 
of these important aspects of care. Each question (indicator) has an assigned threshold 
(listed on the M&E report) which the clinic desires to remain above. When the results 
of the survey are tallied, the QA representative pencils in the patient response rate for 
each question next to the corresponding threshold on the M&E report. The completed 
Monitor and Evaluation report’s are used as an indicator of how successful the 
department was in reaching the thresholds for each of the important aspects of care. 

These Monitor and Evaluation reports are maintained in a binder kept 
by the QA representative and are used at the monthly QA meetings to report on the 
general level of patient satisfaction for each of the important aspects of care. No other 
reports are created using the information obtained from the questionnaires and trends 
in patient responses are not maintained. The Department Chief does not receive a 
copy of the Monitor and Evaluation reports unless he requests them. 

6. Productivity (see DFD, Figure 19) 

The DFD in Figure 19 depicts the current information processes 
involved in reporting productivity for the DFPCM. The CTMC/FP section is the only 
section reporting productivity to the Department Chief. The primary reason for this is 
the fact that the CTMC is an ancillary service specially monitored by the Clinical 
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MONITOR k EVALUATION 



SCOPE PatteDl saiisfaction 

IMPORTANT ASPECT OF CARE: paticDts will be Irealrd courieously and 
professiooatty by ihc sia/f. 



INDICATORS: 

1) Survey indicates records ready at the front dest ’"V 74 

2) Survey indicates screening prompt and private 

3) Survey indicates waiting time will be 30 min or less 



THRESHOLD 




SOURCE OF DATA: patients' survey 
* 

METHOD OF COLLECTION: Family practice receptions clerk provides 
patients vitb survey to be completed after appoiomeot. 

WHO TO COLLECT DATA: Receptions clerk to forward to nurse or QA 
co-ordinator 

SAMPLE SHE: 30 

TIME FRAME: One day per month, every other month starting with 
AugustSS 



Figure 18. Monitor and Evaluation Report 

Support Division. The CTMC/FP appointments and patient visits are tracked by the 
AQCESS system. 

The AQCESS system produces a report called the Validated 
Appointment Roster which shows the acmal patients seen the previous day. This rep>ort 
is sent to the Clinical Support Division which counts the numher of patients acmally 
seen by the CTMC, per provider. A cumulative total is kept for the entire month. At 
the end of the month, the Clinical Support Division enters this information into a 
LOTUS 1-2-3 spreadsheet. The resulting productivity reports are sent to the Chief, 
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DFPCM. These reports provide information on daily, weekly, monthly, quarterly, and 
yearly workload in tabular and graphical formats. Provider productivity is also reported 
in a tabular report showing the number of patients seen each day, by provider, for the 
reported month. 

Although the productivity of all of the sections is not directly reported 
to the Chief, the data necessary for producing clinical productivity information is 
gathered by each section. The remaining sections use either AQCESS, COSTARS or 
manual logs for gathering workload data. Patient visit information is then reported to 
the Patient Administration Division (PAD). PAD collects and forwards all hospital 
workload information to the Health Services Command on the MED 302 report both 
electronically and in paper format. This report is used in the formulation of future 
budgetary allocations to the hospital. Figure 20 illustrates how the various department 
clinics currently input their workload information to PAD. All of the workload data 
collected by the department’s various sections is also stratified according to patient 
demographics, e.g., active duty, dependents, retired, service, etc. 




(IT. BACON, CSD) 



Figure 19. Productivity System Data Flow Diagram 
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The Department Chief wants productivity information for all of his 
clinics, similar to that provided to him by the Clinical Support Division for the 
CTMC/FP clinic. The raw data for creating most of this information exists in the 
current systems but is not being used because of time and personnel constraints, and 



other factors which were not readily identifiable. 




» Input visits by »ppoint*ent Kheduhnq 
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Figure 20. Clinic Workload Data Flow Diagram 
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IV. FUNCTIONAL SPECIFICATIONS 



A. INTRODUCTION 

Chapter HI presented the DFPCM’s current information systems relating to six 
specific areas; budget, equipment procurement, personnel, scheduling, patient 
satisfaction, and productivity. This chapter summarizes the current system’s 
deficiencies and examines the failure of automation to meet the department’s 
information requirements. 

Additionally, this chapter proposes general improvements for each of the six 
areas and discusses the impact of these solutions, and the impact of automation on the 
department’s information systems. The detailed system improvements for each of the 
information systems are presented fully in Chapter V, Requirements Analysis. 

B. CURRENT INFORMATION SYSTEM DEFICIENCIES 

The Chief of the DFPCM makes many decisions which affect both his personnel 
and resources, and greatly impacts the entire hospital. The nature of his responsibilities 
and the span of control he is required to exercise place additional emphasis on the 
significance of these decisions. Facing both time constraints and limited resources, he 
needs the right information, at the right time, and in the best format to accomplish his 
objectives and meet the needs of the department and the hospital. In analyzing the 
existing department information system, we discovered many deficiencies which hinder 
the Department Chief’s ability to make informed decisions. 
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In general, the reports and other information the Department Chief receives are 
complex and difficult to quickly comprehend because they are not summary in nature. 
In interviews with the Department Chief, he expressed a desire for information which 
would depict long term trends and show department performance over a predetermined 
period of time. Much of the information he gets now is a "snap-shot” in time which 
does not allow him to see the "bigger picture" without pouring through many similar 
reports. In a few cases, the data is simply too time consuming to analyze (e.g., 
budget, equipment and personnel information) and, therefore, never becomes meaningful 
information for the Department Chief. 

In addition to poor information, the Department Chief occasionally has difficulty 
getting enough information. One of the Department Chief’s concerns is having sound 
information to help justify his decisions to higher authorities and support his actions 
in managing resources and personnel. Missing information due to informal reporting 
standards or poor data collection impedes his decision abilities in these areas. 

Another concern of the Department Chief is the importance of feedback. The 
Department Chief feels it is critical for each section to receive sufficient, and timely, 
feedback on their performance to allow them to become more effective and efficient 
on there own initiative. The sections currently receive very little in the way of 
constructive feedback and the information they do get is prone to the same problems 
discussed above. 

Unfortunately, inconsistent reporting requirements and system capabilities exist 
throughout the department so that each section is substantially different from the others 
in the information it is able to report. This contributes to many of the problems 
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described in the preceding paragraphs. Succinctly, the current information system is 
not meeting the requirements of the Department Chief. We feel the majority of these 
obstacles can be attributed to limited personnel resources, time constraints, and 
ultimately, the incompatibility of the hospital’s automated information systems. 

C. THE FAILURE OF AUTOMATION TO MEET INFORMATION 
REQUIREMENTS 

Chapter II introduced the three major automated information systems in place in 
the hospital: MEPRS, AQCESS, and COSTARS. These systems hold huge stores of 
data which can potentially produce meaningful information. In addition to these 
medical information systems, the hospital uses other Army-wide systems for accounting 
and logistical data. Microcomputers are scattered throughout the hospital providing 
individual computing capabilities in some functional areas. With all of these resources 
at hand and with the rapid advance in information systems technology, the question 
arises, "Why hasn’t automation solved the information problems within the DFPCM?" 

There are many reasons why the automated systems at SUas B. Hays have faded 
to meet the information needs of it’s key decision makers. The primary factors which 
have contributed to this failure are listed below: 

• The AQCESS, MEPRS, and COSTARS systems are independent and 
incompatible with each other. Data sharing is impractical and duplication of 
data collection and data reporting are wasteful of time and resources. 

• All of the sections within the department do not use the same system. For 
instance, the Family Practice Clinic uses COSTARS for appointments and 
patient records while the Consolidated Troop Medical Clinic, the Family 
Practice Clinic at the Consolidated Troop Medical Center, and the Generd 
Outpatient Clinic use AQCESS for appointments and patient information. The 
Fort Hunter Liggett and Presidio of Monterey Clinics, the Emergency Medical 
Services, and the Flight Surgeon’s Office are completely manual. 
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• Much of the data kept by the accounting and logistical information systems 
is not divided by departments or sections, making information extraction 
difficult and time consuming. 

• The method of inputs to the various systems are different, making it 
impossible to create standards for data collection and reporting. 

• Hospital personnel are not adequately educated on the capabilities of the 
current information systems. In discussions with various department and 
hospital personnel, it was apparent they were unaware of the information 
available to them or of the procedures required to obtain the information. 

• The reports produced by these systems are in tabular format and reflect the 
data for one period of time. Trend analysis over time is impossible without 
further manual manipulation of the data. Summary information is also difficult 
to obtain. 

Although most of these problems are unsolvable within the scope of this thesis, 
evaluating the difficulties they create within the department’s information system will 
assist us in identifying specific requirements for an improved information system. 

D. PROPOSED INFORMATION SYSTEMS 

The first two sections of this chapter addressed the overall problems which exist 
in the current information system. In identifying what the system lacks, we have thus 
helped identify what an improved system wUl require: 

• Consistent data collection methods. 

• Consolidated information. 

• Concise, summary reports which are easy to read. 

• Analysis of department and section performance trends over time. 

• Easy data input methods. 

• Feedback for department and section leaders. 
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• Standard reports. 

• Complete and up to date information. 

The remainder of this chapter is an analysis of the requirements for each of the 
specific areas described in Chapter HI. Each section below summarizes the solutions 
we propose, supported by the Department Chief’s requests, for the six major areas 
under consideration. 

1. Budget Information System 
a. System Deficiencies 

The Department Chief has a budgetary system that meets only his 
minimal needs. The information listed below is provided to the Department Chief in 
tabular format by the microcomputer based spreadsheet program. 

• Account Processing Code (APC). This code is generated by the Re.source 
Management Division to identify separate identified fund accounts. A single 
section can have several fund accounts. 

• Section name. The name the department assigns to each APC listed above. 

• Allocated funds for the Quarter. The funds allocated for each APC for the 
quarter. 

• Supply Expenditures for the Month. 

• Total Department Expenditures for the Month. 

• Total Spent this Quarter (cumulative) 

• Uncommitted Funds this Quarter. 

• Funds per Month (target expendimre for the section). 

• Percent Spent for Month. 

• Percent Saved for Month. This percentage is calculated by subtracting the 
percent spent for the month from 100 percent. 
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• Percent Spent for Quarter. 

• Percent Saved for Quarter. This percentage is calculated by subtracting the 
percent spent for the quarter from 100 percent. 

This information, though adequate, does not provide him with an easUy decipherable 

format nor the capability to track spending habits for more than one month. The data 

used to generate the report, the Month End Report, is accurate but does not necessarily 

reflect any recent section expenditures. In spite of this problem, the information from 

the Month End Report is still considered accurate enough to be a good indicator of 

expenditures for the Department Chief. 

The Department Chief also receives budget information from the two 
intradepartmental reports, the Resource Information Report (RIR) and the Budget and 
Equipment Analysis Report (BEAR). The budget sections of these reports are meant 
to provide the Department Chief with up to date budget information that is not 
currently reflected on the monthly budget worksheet. Though these reports were 
designed to report more current budget information, the information actually reported 
on the RIR and BEAR reports is a duplicate of the budget information already 
provided on the budget worksheet. In fact, the Department NCOIC stated that he often 
recopies the budget data onto the reports from the Month End Report. 

The Department NCOIC currently maintains old copies of each budget 
report on computer disks. As each new report is needed, the Department NCOIC 
gathers the current information necessary' to complete the spreadsheet. He gathers this 
data from either the current Month End Report or in the case of a quarterly or yearly 
recap report, from previous monthly reports. Once this new spreadsheet is created for 
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the report, he enters the sections’ expenditures for the period into the spreadsheet. The 
input of each section’s expenditure requires the Department NCOIC to search through 
the spreadsheet and find the location where the information must be entered. Although 
this process is not necessarily difficult, it is cumbersome and requires the Department 
NCOIC to have a working knowledge of both the spreadsheet’s format and the 
application program. This system can be handled by a highly computer literate 
individual like the current Department NCOIC, but could easily become unworkable 
under a different NCOIC. 

Data analysis requiring more than one month’s data would involve the 
combination of several separately maintained spreadsheets. The old data is replaced 
each time a new report is created. The elimination of historical data makes long term 
trend analysis extremely difficult and cumbersome. 
b. Proposed System Improvements 

Data entry can be made simpler by standardizing the screen displays 
and inputs and by making the program environment transparent to the user. This data 
can also be maintained in a more accessible format, such as a database, for ad hoc 
inquiries. Maintaining the data within one consolidated database will also provide the 
capability to do long term analysis of expenditures. This ability to access the data 
allows the sections to retrieve information on their performance in the same format as 
seen by the Department Chief. 

The data output can be improved through the use of graphs. The 
graphs will be used to display budgetary trends on a yearly basis which provides the 
Department Chief with a clearer picture of the budget fluctuations and trends over 
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time. These graphical printouts allow better analysis of the budget information with a 
lot less mental manipulation of the data. Printed tabular reports can be improved by 
reorganizing the presentation of the information, 
c. Impact of Automation 

Dr. Enel best characterized the role of the microcomputer in automation 
by his statement: 

The proper role for the computer is to do what it does best: scan large numbers 

of records. ..rapidly, apply its infallible memory for detail, and serve as a 

communications link. (Ertel, 1984, p. 485) 

The primary goal in our requirements specification is to avoid the creation of any 
additional and senseless work. This means avoiding the automation of something that 
does not need automating whUe automating those things that best fit the advantages of 
the microcomputer. 

The budget system is already automated, though only in a limited sense. 
The improvements described in the previous section will have the following impact on 
the current information system: 

• Simplification of the input process. 

• The capability to maintain a larger database to facilitate trend analysis and 
graphing. 

• Enhance the information’s worth to the decision maker. 

• The capability to graph the data versus displaying it in its current tabular 
format. 

• Reduce the amount of time the person who receives the uiformation must 
spend in deciphering the data to turn it into useful information. 

• Provide for a user friendly system that will not require the user to master a 
computer or to learn a particular applications program. 
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• Providing the user with a menu driven work environment should make the 
transition between tisers less complicated. 

• Enhance the choice of outputs (the ways the data can be viewed) for the 
Department Chief and his sections. 

d. Impact of Proposed System 

The information provided by the new budget information system will 
provide the decision maker with a more succinct view of the budget information than 
he currently receives. As discussed in the introductory sections, the Department Chief’s 
time is limited and the ability to see the impact of information quickly without any 
major data manipulations is critical. The addition of a trend analysis capability will 
provide the Department Chief with the ability to forecast and manage his future budget 
requirements. By being able to pictorially depict his budget trends and status, the 
Chief can keep himself, his subordinates, and his superiors better informed. 

2. Equipment Procurement System 
o. System Deficiencies 

The current equipment needs are identified through three sources: the 
Resource Information Report (RIR), the Budget and Equipment Analysis Report 
(BEAR), and the Information Capability Request (CAPR). The equipment needs 
identified by each of the department’s sections are provided by the equipment sections 
of the RIR and BEAR reports. The Department Chief identifies new automated 
equipment requirements through the Information Capability Requests (CAPR). 

The RIR contains the following equipment information: 

• Old Equipment Status. 

• New Equipment Status. 
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• Medical Care Support Equipment (MEDCASE) items (equipment needed). 

• Capital Expense Equipment Program (CEEP) items (equipment needed). 

The BEAR contains the following equipment information: 

• Equipment to be replaced (immediately, within one year, within two years, and 
within three years). 

• Money needed for equipment replacement (immediately, within one year, 
within two years, and within three years). 

• Actual approved items now on the CEEP and MEDCASE program with the 
date item ordered and its projected arrival date. 

• Paper work in progress for placing equipment either on the CEEP or 
MEDCASE programs and its paperwork status. 

The problem with the information provided in the RIR and BEAR reports is 

redundancy. Each report seeks to collect information on only the high priority 

MEDCASE and CEEP requirements but within two different timeframes, quarterly for 

the BEAR and monthly for the RIR. These reports provide the Department Chief with 

only a limited look at his equipment needs and tend to track only those needs that are 

the most urgent (usually only MEDCASE and CEEP items). The reports do not give 

the Department Chief a consolidated look at all of his department’s requirements. This 

fragmented approach to capturing the data makes it an intricate process for the 

Department Chief to estimate his future equipment needs. Since funds are limited, the 

Department Chief stated that he needs a consolidated listing of all his requirements to 

set replacement priorities throughout the department. The consolidation of this 

information would also be beneficial when bargaining with the hospital’s equipment 

acquisition board (Programmed Budget Advisory Committee). 
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The CAPR requests provide the Department Chief with the following 

information: 

• Functional area supported, i.e., automation, communications, records 
management, printing/publishing, and visual information. 

• Justification for the equipment. 

• A description of the changes and the reasons for the change to the existing 
service (if applicable). 

• Source of funding for the equipment. 

These requests are only tracked as they are generated. 

The process of consolidating the equipment requirements identified in 
the BEAR, RIR, and CAPR requests is tedious and requires the Department Chief to 
manually consolidate all the section’s separate reports. The current system also does 
not allow him to track the long term equipment requirements needed to determine if 
there are department-wide problems in the acquisition of equipment. 

Other equipment needs that may not be as critical are not tracked or 
monitored. In addition, the Department Chief cannot track the section’s past reported 
requirements which are either inadvertently or deliberately not listed on the current 
report. This requires him to either remember all of the past requests or manually 
search through the old RIR and BEAR reports to obtain this information. 

The status of high priority equipment requests are reported on the 
BEAR and RIR reports. The only way to see the status for this equipment is to review 
each section’s RIR and BEAR reports for this information. The Department Chief 
simply does not have the time to do this. 
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b. Proposed System Improvements 

Any solution proposed for the equipment information system will 
undoubtably create some additional work for the department. Therefore, the primary 
consideration for the new equipment information system will be ease of data entry and 
familiarity with the entry format. The greatest improvement to the current system can 
be accomplished by the creation of a consolidated database where all equipment 
requests can be recorded and easily tracked. To identify equipment requirements, the 
Department NCOIC suggested the following types of information be used in the 
database: 

• Item description. 

• National Stock Number. 

• Section requesting the equipment. 

• Date requested. 

• Type of request (MEDCASE, CEEP, CAPR, Other). 

• Priority of equipment within a category. 

• Urgency of need (immediate, one year, etc.). 

• Quantity desired. 

• Unit price and associated extended price. 

• Status of request (requisition number). 

• Cumulative recap of required expenditures. 

Once an item is deleted from the active database due to the delivery of the equipment, 
its data should be relegated to a historical database for the analysis of long term 
equipment trends. 
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The design of the user interface is critical. Once again, data entry 
should be simple and straightforward. The outputs can reflect either a recap by 
equipment category or a consolidated listing of all equipment requirements. The current 
reports should be consolidated into a single report and standardized and simplified to 
match the inputs required by the user data entry interface. Tlie system should be buUt 
to facilitate ad hoc inquiries on the database and to do limited mathematical 
calculations to subtotal categories and run cumulative totals within categories, 
c. Impact of Automation 

The equipment procurement information system is not currently 
automated. The most far reaching impact of automating this system will be the work 
required to enter data from the consolidated Resource Information Report into the new 
equipment database. On the other hand, the Department Chief considers the 
availability of this information important for resource management. As stated earlier, 
a well designed user interface should limit data entry to the format recognized in the 
RIR. Specifically, automation wUl; 

• Provide the department with a consolidated listing of all equipment 
requirements and the capability to report separate categories without leaving 
the database. 

• Provide the Department Chief with the ability to request the information in the 
format he needs for a particular situation. 

• Provide a historical database of equipment requirements that can be analyzed 
to determine equipment procurement trends over the long term. 

The Department Chief currently feels that the benefits associated with automation in 

this area will far exceed the costs, provided the user interface is kept simple. 
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d. Impact of Proposed System 



The proposed system will provide the Department Chief with a 
consolidated listing of all his sections’ equipment requirements. This information will 
provide him with a capability to sort equipment needs by cost, category, or priority 
within the separate equipment categories, e.g., CEEP, MEDCASE, etc. In this 
information lies the ability to bargain with the hospital resourcing committees by 
having the information readily at hand and in a format which will facilitate this "give 
and take" environment. By knowing all of his requirements, the Chief can better 
manage his resources to meet those equipment needs that are the most critical to his 
department’s success. With his limited time, the consolidated format allows him to 
digest the information quickly. Through the listings of future needs, he can better plan 
the budgets to meet those needs. This new system will serve to facilitate unique 
information needs quickly and with less inconvenience in obtaining that data. 

3. Personnel System 

a. System Deficiencies 

As discussed in the previous chapter, the Department Chief has two 
areas of concern with the personnel information system: tracking and reporting 
manpower levels and funding for the Continuing Medical Education (CME) program. 

The Department Chief currently tracks personnel manning levels by 
maintaining this information within a word processing shell. TTiis format is not ea.sy 
to update. It limits the types of reports you can generate and the type of analysis that 
can be done on the data. Without an ad hoc capability, the Department Chief must 
visualize position vacancies by scanning the complete listing. This format also restricts 
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the types of additional data that can be maintained with the personnel listing, i.e., 
doctor patient panels, productivity information, or leave and absence requests. This 
also precludes any data interfaces with other information systems, such as scheduling. 
The update process is complicated in that it involves printing the entire form and then 
cutting the report into individual sections. Likewise a section which requests a listing 
must be satisfied with a department-wide listing. 

The CME listing is currently maintained on a spreadsheet. This type 
of format, though adequate, hampers the ability of anyone to do ad hoc analysis. Any 
trend analysis beyond the current year is limited. A person unfamiliar with the 
application program may have difficulty updating the CME spreadsheet. 
b. Proposed System Improvements 

The current personnel listing can be integrated into a database to 
provide the Department Chief with the capability to keep critical personnel information. 
The database should contain the following database files: 

• Position Information (TDA position, authorization, etc.). 

• Personnel Information (Name, SSN, and Known Loss Date). 

• Personal Information (Protected, including address, spouses name, children, 
birthday, telephone number, etc.). 

• Leave/Absence Log (Interfaces with CME listing and scheduling system, but 
would also include other types of absences, i.e., leaves, emergency leaves, 
other TDY, or unusual planned absences). 

• CME listing. (Interface with the Doctor listing and the Absence Log hut also 
includes critical CME information, i.e., estimated costs, actual costs, 
qualification, etc.). 
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TTie various relationships between the database files can be kept transparent to the user. 
All requested reports can be created by linking the needed database files. The 
Department Chief will have access to a list of planned absences, anticipated losses, and 
vacancies that he did not have previously. The consolidation of the CME listing with 
the personnel listing will consolidate the data entry requirements under one person, 
therefore freeing critical personnel to do their primary jobs. This type of data format 
facilitates any type of report the sections or the Department Chief could request. In 
addition, the scheduler can receive a list of the planned absences and not have to rely 
on verbal notifications from the doctors (see Section D.4., Scheduling). 

Once again, by building a user interface that is independent of the 
program used, the requirement for any application programming familiarity is no longer 
necessary. 

The current system requires two separate routes for leave requests, 
depending on the person requesting leave. The flow of information can be improved 
by centralizing all the data entry and flows for leaves into one location. By 
centralizing this data flow, the leave requests, as well as personnel updates, can be 
combined to avoid the redundancy of the data maintained, 
c. Impact of Automation 

Automation wUl improve the system in the following areas: 

• Improved user interface. The system can be independent of the knowledge of 
the user. 

• The choice and diversity of reporting capabilities wUl be enhanced. 

• The leave log is currently maintained manually. By automating this log, the 
data can be linked to the other systems, particularly the scheduling system. 



75 



• The data will be made easier to maintain and to update. 

• The Department Chief will be able to maintain a protected personal database 
on his personnel. 

• The need to consolidate all data flows through one central location will involve 
changing some internal procedures within the department. These changes must 
be validated to meet regulations and will cause some personnel changes. 

• The initial setup will be costly in terms of the database. The maintenance of 
this large database will require the use of a data entry clerk, but the work can 
be minimized by a well designed user interface. 

d. Impact of Proposed System 

With an enhanced database, the Department Chief can maintain the type 
of data he needs to track his personnel. Through a vacancy listing and the anticipated 
loss listing, the Department Chief can always know, with one simple listing, the 
vacancies or projected losses that exist in his department. This information can then be 
used at critical hospital meetings to quickly identify his needs in a straightforward 
format. At the same time, the addition of personal information, readily accessible to 
him, makes his Job as senior counselor easier. The absence listing gives him a monthly 
listing of the personnel that will not be available during a specified time period. This 
information is critical for monitoring the workload throughout the department and 
greatly enhances the Department Chiefs ability to predict periods of high stress due 
to personnel shortages. The management of CME funds will always remain critical. 
Doctors need the necessary education to keep them up to date in their medical practice 
but in periods of increasing resource constraints, the ability to predict and justify’ these 
requirements is critical. 
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4. Scheduling System 

a. System Deficiencies 

Scheduling is a complex, subjective process requiring a great deal of 
independent information. In the existing scheduling system, this information is 
collected in many different ways, at different times, and in different formats. This 
information is subjectively interpreted and evaluated to produce the three required 
Family Practice schedules and the CTMC/FP schedules. Specific problem areas within 
the current scheduling process (as shown in Chapter m. Figures 15 and 16) are listed 
below; 

• Doctor’s leave and TDY requests are verbal. The scheduler depends on the 
individual doctor to inform him of upcoming absences. There is no standard 
form or time requirements for providing this information. 

• The independent sources of information are maintained informally, i.e., some 
are recorded on yellow legal paper, other information is kept on 3" x 5" cards, 
and stUl others are typed on regular white paper. 

• There is no formal instruction for the collection or maintenance of the 
information necessary for scheduling. The Assistant Department Chief (ADC) 
currently keeps all the scheduling paperwork in a manila folder and the 
CTMC/FP chief has a green log book in which he records doctor availability 
information. 

b. Proposed System Improvements 

The subjective nature of the scheduling process and the diverse sources 
of the necessary information place restrictions on the improvements which can be made 
and the resulting benefits of these improvements. We feel attempting to automate the 
process, in this case, is infeasible. Automated scheduling applications requires integer 
programming and optimization techniques far beyond the scope of this thesis. 
Additionally, complex scheduling algorithms often require the computing power of a 
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mainframe computer for the rapid calculations and reiterations of scheduling models. 
(Lyons, 1983, p. 438) Therefore, instead of concentrating on the process of actually 
creating the schedule, we propose improved methods of collecting, maintaining, and 
assimilating the necessary information. Developing a scheduling optimization model 
could be the subject of future research. 

As described in the previous section on the Personnel System, an 
automated leave/TDY log could be used to record all requests for leave as soon as 
they are approved by the Department Chief. A simple report listing each doctor’s 
requested leave dates could be produced for the ADC just prior to the creation of the 
following month’s schedule. This would ensure the ADC had all doctor’s leave and 
TDY dates, without having to rely on verbal information or "Post-it-Notes" stuck on 
his office door. 

In evaluating the other methods for collecting and maintaining doctor 
information, we found that automation would again be infeasible. In this case, the 
department schedulers do not have ready access to microcomputers and wUl probably 
not have access in the near future. Additionally, automating manual records can 
sometimes cause more work than it saves. For instance, in keeping the monthly 
cumulative tally sheet described in Chapter III, the ADC simply puts tick marks beside 
doctors names to show how many times they were on call for the month. If this tally 
sheet were automated, what now takes the ADC 2 or 3 minutes to perform might take 
10 or 15 minutes by the time he turns the computer on, loads the application program, 
and selects and updates the doctor’s information. 
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Improvements can be made, however, if the forms for recording and 
reporting information are standardized and a more formal method of coordinatuig the 
information is developed. Using the monthly cumulative tally sheet to illustrate, 
preprinted forms with the months of the year listed across the top and the doctors 
names on the left could be used instead of the handwritten yellow legal paper. Other 
forms depicted in Chapter III, Figures 15 and 16 could be standardized and preprinted. 
This would make formalizing instructions easier and would positively influence the 
scheduler’s assimilation of data when producing the schedules. 

Keeping these standardized forms in a folder or binder is sufficient, as 
long as there are some basic instructions on where to get the printed forms (e.g., the 
department secretary’s office) and the doctor’s leave report so that a newcomer to the 
job wUl not revert to an unorganized system. 

c. Impact of Automation 

As presented in the last tw'o sections, automating the scheduling process 
for the DFPCM would be infeasible within the scope of this thesis. Where automation 
would benefit the scheduling process is in providing consolidated information 
concerning doctor’s leave and TDY requests. This is discussed more fully in the 
section on personnel. The preprinted forms for standardizing the information collection 
and maintenance functions could be created and kept on a floppy disk in the 
department’s administrative office. They can then be printed as needed by the ADC. 

d. Impact of Proposed System 

The improvements suggested for the scheduling system deal mainly 
with organization and standardization of the information collection, maintenance, and 



79 



reporting functions. Although the process will remain virtually the same, the 
schedulers will find it much easier to gather and assimilate the data concerning the 
individual doctor’s availability status. Designing a good manual user interface (forms, 
reports, instructions, etc.), like designing a computer user interface (menus, data entry 
forms, reports, screens) is important. "You will learn and use a system better if it has 
a consistent user interface." (Burnett, 1988, p. 29) Organizing and standardizing the 
various forms and reports will assist the scheduler in recording, finding, and 
understanding necessary information. It wUl also be much easier for him to explain 
the system when he turns the scheduling job over to another person, as often happens 
in the military. Clear instructions are vital for a good transition file. 

The process of scheduling department doctors will, for the time being, 
remain a subjective decision making process. Formalized methods of collecting and 
reporting information, however, will ease the process by allowing the department 
schedulers to more rapidly assess the information presented to them. 

5. Patient Satisfaction System 
a. System Deficiencies 

Patient satisfaction is difficult to define and measure. The concept of 
satisfaction is viewed differently by each patient and is influenced by different factors. 
One person may base satisfaction on the courtesy of the doctor, another on the amount 
of time he had to wait to see the doctor. Some people agree that hospital satisfaction 
is "the consumer’s overall emotional feelings about a hospital following his or her 
visit" (Swan, and others, 1987). Because of the differences in opinions on this matter, 
it is important to identify some basic dimensions which might be indicators of 



80 



satisfaction. The evaluation of these dimensions can then be determined by using a 
questionnaire to measure patient opinion on the various dimensions. It is also 
important to realize that "many questionnaires are developed not with the intent of 
determining global patient satisfaction, but instead, to address only those dimensions 
of satisfaction with which an organization is willing or able to react". (Pelletier, 1985) 

Applying these concepts to the DFPCM involved evaluating the 
effectiveness of the current patient satisfaction questionnaire and the value of the 
information it provides. 

The basic content of the current questionnaire closely matches the 
Department Chief’s desires. Table IV shows the dimensions of satisfaction perceived 
by the Department Chief as necessary for effective evaluation of patient satisfaction. 
The current questionnaire covers most of these dimensions except as noted in Table IV. 
The questionnaire lacks two important features: a brief explanation of the purpose of 
the questionnaire; and instructions for completing and submitting the questionnaire. The 
patient currently receives verbal instructions from the doctor distributing the 
questionnaire. These instmctions wUl vary slightly from doctor to doctor. 

The format for obtaining patient response is not as effective as it could 
be. Instead of "YES/NO" questions, the Department Chief would like the answers to 
be scaled, e.g., options from poor to excellent using a scale of one to five. "YES/NO" 
questions are considered too restrictive while a scale indicates a degree of intensity 
(EXiffe, 1985). For our purposes, a scale would show the general level of patient 
satisfaction with respect to the given dimensions. 
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Table IV DIMENSIONS OF SATISFACTION 



ACCESS TO CARE 

WAITING TIME 

COURTESY OF STAFF 

UNDERSTAND TREATMENT 

CLINICAL ENVIRONMENT 

PHYSICIAN TIME 
ALLOCATION 



How long it takes to get an appointment. 
How long it takes to see a doctor. 
Doctors, Nurses, Clerks. 

Explanation of procedures. 

Cleanliness of clinic. 

Adequacy of time spent with doctor. 



GENERAL SATISFACTION 
** Dimensions not Included in current questionnaire 



General opinion of the care received for a particular 
visit. 



The primary problem with the existing system is in the output generated 
from the questionnaire results. Each question is treated as a discrete entity, one 
indicator of an important aspect of care. As such, only one-time, discrete response 
rates can be obtained for each question. Additionally, the questionnaire results are not 
being tracked or reported. As discussed throughout this thesis, the Department Chief 
wants summary information which depicts comparisons and trends. The Monitor and 
Evaluation reports do not provide this information. 
b. Proposed System Improvements 

There are two basic improvements which need to be made for the 
patient satisfaction system. First, the questionnaire must be redesigned to include all 
of the dimensions of satisfaction identified by the Department Chief, listed in Table IV. 
This redesign must also incorporate the desired scales for applicable questions. In 
addition, the questionnaire should include a statement of purpose and instructions to the 
patient on how to complete and submit the questionnaire. Although some literature 
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suggests that a cover letter be included (Landry, 1987, p. 16), we believe a simple one 
page questionnaire will be received better by the patients and will be easier to collect 
and review. 

Secondly, the results of the questionnaire need to be reported in a more 
meaningful, effective method. The Department Chief should be able to view trend 
lines and other graphical information to determine the level of satisfaction with respect 
to various dimensions. Comparing the dimensions, when appropriate, should also be 
made easier. Providing this information using automation would require the 
questionnaire data to be entered into a computer program which would manipulate and 
compute the desired results and produce the desired output. 
c. Impact of Automation 

If the responses in the questionnaire are coded, the patient response can 
be easUy entered into a computer. Once this is done, the application program would 
automatically compute the results and print or display the desired output in tabular or 
graphical form. Automation will allow rapid trend analysis and graph generation and 
provide a means for storing historical results for future analysis if desired. To perform 
these functions manually would require an inordinate amount of time and the resulting 
benefits would thus be outweighed by the costs. The Department Chief has clearly 
stated the shortage of personnel in his department precludes implementing any system 
which would require excessive input or evaluation time. The time the QA representative 
now spends hand calculating the results of the current questionnaire would be converted 
to time spent by a data entry clerk entering the raw data from the returned 
questionnaires. 
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d. Impact of Proposed System 



The proposals outlined above will improve the patient satisfaction 
information system in several ways: 

• A questionnaire which is easy to understand and complete is more likely to 
be submitted by the patients. 

• Improved questions will meet the Department Chief’s stated dimensions of 
satisfaction. 

• Redesigned answer formats (scales) will provide more meaningful information 
to the Department Chief on the level of satisfaction of the patients. 

• Automated applications wiU free the QA representative from the time 
consuming task of hand calculating the response rates for each question. 

• Through automation, improvements in data analysis, storage, and reporting can 
be realized with minimal time requirements. 

• Producing more meaningful reports will allow the Department Chief to spend 
less time analyzing the data and draw more accurate conclusions from the 
information presented. Trend analysis and historical comparisons will give 
indications of p>ossible problems and potential improvements in the care 
provided by the department. 

6. Productivity System 

a. System Deficiencies 

The main problem with the productivity information system is that only 
the CTMC and CTMC/FP clinics are being monitored for productivity. The 
Department Chief likes most of the tables and graphs produced by the Clinical Support 
Division for the CTMC clinics but would like to receive this information for each of 
his other sections. Unfortunately, all of the sections do not use the same system to 
record patient visits and doctor workload. CTMC uses AQCESS, Family Practice uses 
COSTARS, and other sections use a manual system. Thus, to provide the Chief with 
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the information he desires will require collecting and consolidating the clinic and 
doctor workload statistics from each separate clinic. 
b. Proposed System Improvements 

The Department Chief is interested in obtaining productivity information 
for two distinct purposes: monitoring each individual doctor’s workload (based on the 
number of patients seen), and monitoring the overall workload of each clinic (based on 
the total number of visits). 

Monitoring each doctor’s productivity was determined to be beyond the 
scope of this thesis for the following reasons: 

• Only clinics using automated appointment systems, i.e., AQCESS and 
COSTARS, maintain individual doctor workload data. 

• Productivity information for each doctor would be impractical to obtain 
manually because of the high volume of patients treated by each clinic. 

• The appointment systems use different measures of doctor availability and do 
not factor in doctor absences, e.g., leave and TDY, when computing doctor 
workload. These disparities result in inconsistencies between the resulting 
doctor productivity figures. 

For these reasons, individual doctor productivity will not be discussed in the remainder 
of the thesis but could be the subject of future research. 

Overall clinic workload data, in terms of the number of patient visits, 
is reported monthly by each section to the Patient Administration Division (PAD). This 
information is already mandatory and can be obtained from PAD either manually from 
the printed MED 302 report or automatically from the data in the PAD worksheet (see 
discussion in Chapter lH). The use of an automated data capture routine wUl preclude 



85 



the sections from having to provide another copy of their workload reports to the 
department. 

The improvements necessary to obtain the clinic productivity 
information involve collecting all of the section’s visit data for entry into an overall 
department system. With a consolidated database of department visit information, 
productivity reports can be produced to show monthly clinic workload and yearly 
productivity trends. The productivity database can be combined with the budget 
database to produce information relating department and clinic monthly expenditures 
to monthly workload data. 

c. Impact of Automation 

Automating clinic workload reporting would result in the following 

benefits: 

• The Chief can monitor the aggregate workload, by section, to determine trends 
in patient visits and the need to shift resources to meet needs. 

• The department will be able to monitor its workload in relation to its budget. 

d. Impact of Proposed System 

The aggregate number of patient visits is important information. The 
number of patients seen by a section can be compared with the dollar amounts of 
supplies used to track and estimate budget requirements and justify spending patterns 
for the Department Chief. The trends and seasonal changes in patient visits can be 
analyzed over time to assist the Department Chief in planning for future requirements. 
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V. REQUIREMENTS ANALYSIS 



A. INTRODUCTION 

This chapter presents the requirements analysis for the DFPCM information 
system. These requirements were determined through prototyping as discussed in 
Chapter II. The requirements analysis is based on the functional specifications for each 
system described in Chapter IV and provides a more detailed look at the inputs, 
outputs, data structures and user interfaces required to meet the functional 
specifications. We used User Concept Diagrams (UCDs), described in the following 
section, to depict the requirements for the systems and aid in establishing the 
prototypes. 

Having analyzed the current system (Chapter III) and proposed improvements 
(Chapter IV), the requirements analysis is the first step toward actually building an 
improved information system. This thesis takes the requirements analysis phase of the 
development life cycle through one iteration of the requirements prototype. The 
number of iterations w'hich will ultimately be required for the prototype is unknown 
and will vary for different development projects. Once the prototypes are accepted by 
the users, the system development can continue with design and implementation. The 
remainder of the chapter presents the identified requirements for the DFPCM 
information system. 
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B. IJSF.R CONCEPT DIAGRAMS 



Chapter m introduced data flow diagrams as a way to depict the current 
information system. Although DFD’s are being used extensively by systems analysts, 
there are many other methods available for relating information system functions and 
data flows to the user. One of these methods is the User Concept Diagram (UCD) 
developed by Charles F. Martin in 1988. 

Martin designed UCDs to supplant DFDs for representing the information system 
to the user. UCDs have several advantages over DFDs. These advantages result from 
the use of additional symbols to represent entities and interactions not present in DFDs. 
The major advantages are listed below: 

• External entity symbols clearly indicate data flows into and out of the 
automated system. 

• The use of multiple symbols for external entities more closely depicts the 
objects they are intended to represent. 

• The intended user is identified with his type of interface so the interactions 
of the system can be designed for compatibility with intended users. 

• Symbols can be easUy drawn with standard flow chart templates or automated 
graphics packages. 

• Different storage and output mediums can be easily portrayed. (Martin, 1988, 
pp. 65-84) 

Figure 21 shows the basic UCD symbols (more can be created to meet a 
particular analyst’s needs). Although UCDs use more symbols, the re.sulting diagrams 
are easier to explain to the users because they are "pictorially more suggestive of the 
objects they represent" (Martin, 1988, p. 65). We found this to be true in our 
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interactions with the DFPCM users. Thus, in the requirements analyses that follow, 
we use UCDs to depict the department’s information system requirements. 



Automated 

function 



Screen display 



Data flow 




On-line date 
store 



Hardcopy reports 



Diskette storage or 
O communication of data 

D 



External entities 




Off-line data 
storage 




Indication of 
intended user and 
type of workstation 




Indication of major 
user and machine 
interaction with the 
given function 



Figure 21. User Concept Diagrams 



C. GENERAL REQUIREMENTS 
1. User Interface Design 

The design of the interface is perhaps one of the most critical aspects in the 
development of a prototype for the DFPCM. "Ease of use", "user friendly", and 
"ergonomic design" are all industry buzzwords that simply mean one thing: make the 
interface woik for the user in the way they expect it to work in their environment. 
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Many factors determine who will be the users and when and how they will use the 
system. The environment at the hospital provides a challenging set of circumstances 
for the design of the interface. The target DFPCM information system user will most 
likely be a novice, untrained in both computers and applications programs. He or she 
will not have the time to learn complicated applications program because of many 
more urgent duties. The information system wUl not have dedicated data entry clerks 
and wUl, in all probabUity, rely on the availability of someone who has other pressing 
matters at hand. 

Martin’s Human Factors/Computer Knowledge Structure, as depicted in Table 
V, served as the basis for the interface designs in developing the initial prototype 
(Martin, 1987, p. 335). 

To properly humanize software through the use of ergonomic design 
principles, Knittle and Gardner suggest the designer follow the principles listed below 
(Knittle, 1987, pp. 164-171): 

• Minimize worker effort. Tlie user should only perform essential, 
non-automatable tasks, avoiding repetition of work already accomplished 
(Knittle, 1987, p. 164). All inputs should be in the format that the user is 
already famUiar with, i.e., a commonly used written form or report. 

• Minimize worker memorization. 

• Minimize worker finstration. Keep the user aware of delays in accomplishment 
and if necessary give them progress reports (Knittle, 1987, p. 166). 

• Maximize use of habit patterns. 

• Notify users of problems prompdy. 

• Maximize worker control of tasks. 

• Maximize task support. 
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Table V HUMAN FACTOR S/CO WUTER KNO\^TEDGE STRUCTURE (Martin and 
Fuerst. 1987, p. 335) 



Human factor 


Human subfactor 


User computer knowledge 


Novice 


Experienced 


Nature of messace 


Tone 


Explanatory' and 
polite 


Short and to the 
point 


Use of humor 


Careful 


None 


Bypasses 


None 


Allow 


Warnings 


Many 


Rarely 


Screen format 


Menu 


Inquiry 


Input verification 


Always 


Rarely 


High lighting 


Some (judiciously) 


Little 


Defaults 


With explanation 


Without explana- 
tion 


Screen discontin- 
uation 


Prompt and keyed 
response 


Keyed response 
without prompt 


Help function 


Procedures 


Full, unsolicited 


Upon request 


Values 


Full, unsolicited 


Upon request 


Response time 


Mean 


Minimize within 
variance 


Minimize 


Variance 


Minimize 


Minimize within 
mean 


Path process 


.Menu structure 


Depth 


Breadth 


Overall screen 
density 


Minimize 


Maximize 



Screen design is another aspect of humanizing software. Stahl recommends the 
following guidelines in the design of screens which support user friendliness. (Stahl, 

1986 , p. 60 ). 

• Do not crowd the screen. "Good screens look good." 

• Use highlighting, blinking, and reverse video sparingly. Overuse will lead to 
operator fatigue. 
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• Use color sparingly. Color is an appealing and proven way to enhance 
computer input. The following foreground/background screen combinations are 
listed in order of legibility, from the most legible to the least legible (Ives, 
1982, pp. 15-47). 

MOST LEGIBLE Black on Yellow 
Green on White 
Blue on White 
WTiite on Blue 
Yellow on Black 
WTiite on Red 
WTiite on Orange 
WTiite on Black 
Red on Yellow 
Green on Red 
Red on Green 

LEAST LEGIBLE Blue on Red 

• Limit the amount of information on each screen to what is necessary. Do not 
force the user to remember things from one screen to the next. 

• Minimize key strokes. 

• Minimize cursor movement. 

• Show the maximum permissible length of an input field with underscores, 
highlighting, or brackets. 

• Keep the screen consistent with paper input forms. Although all information 
from the paper form may not need to be entered on the screen, the screen 
should follow the general flow of information on the paper form. (Kendall and 
Kendall, 1988, p. 484). 

Messages to the user, an essential element in user friendly screens, should 
be: (1) consistently positioned, (2) short, meaningful, common and fully spelled out, 
(3) affirmative, (4) in the active voice, and (5) in the temporal sequence of events. 
(Galitz, 1983, p. 9). 

Another aspect of interface design is the design of menus. The user should 
be able to identify which transactions are available through a series of logically related 
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and relevant events common to a menu screen. The menu screens for the DFPCM 



information systems are depicted in the following sections by the use of Menu 
Hierarchy Charts. 

2. Standard Interface Designs 

Understanding the importance of a good user interface, we designed a set 
of standard interfaces for getting user input and for displaying output on the screen for 
each of the systems. The following sections describe the standard input and output 
designs which are applicable to all of the systems. Within the detailed requirements 
for each system, we present a specific description of the data required for the inputs 
and outputs related to that system. Appendix A, the Data Dictionary, contains detailed 
information about the data structure of the system’s databases. 
a. Input Screens 

The majority of the input screens were generated with a commercially 
available database screen generator. The screen generator displays the available fields 
from the database in use and allows the analyst to load and position the desired fields 
onto the screen to create a functional input format. The program which generates this 
screen is saved and called into use whenever the user selects an input option from one 
of the menu systems. Appendix B is the program listing of all of the format screens 
for the DFPCM information system. 

The screen generator allows the system designer to easily load and 
manipulate the necessary input fields to create good user interfaces. The screen 
formats are easy to change to suit the user’s requirements, making the generator an 
invaluable tool when prototyping the requirements analysis. Examples of each of the 
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input screens designed are included with the detailed requirements analysis for each 
system, with a description of the necessary input fields. 

Other standard input screens are those used to accept input from the 
user necessary for identifying further processing requirements, such as the year and 
month for a desired report or a person’s identification number for updating his or her 
personal information. These screens are created with programming commands which 
identify where the prompts and input blocks appear and any other information needed 
on the screen. An example of these interactive screens is shown in Figure 22. Where 
possible, we have designed these screens to position prompts, input blocks, and 
instructions in the same locations and with similar terminology. Whenever the user is 
asked to input a coded response, e.g., the Section Code shown in the example, he or 
she should be allowed to view a help screen showing the valid codes for that particular 
item, e.g., FPC = Family Practice Clinic. 



Enter the Year tor report: 89 
Enter the Month for report: 10 



Enter the Clinic section code for report; FPC 



Figure 22. Sample Interactive Input Screen 
b. Review Screens 

In many of the sy.stem menus, there is an option for reviewing database 
information on the screen. The review screens are easily created with commercially 
available database software (e.g., DBASE III+) by using a programming command and 
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specifying the fields desired for display. An example of a typical review screen used 
in the DFPCM information system is shown below. 



APC 


DESCRIPTION 


SECT CODE POC 


TELEPHONE 


W357 


FAM PRAC CLINIC 


FPC 


TURNER 


8888888 


W358 


CTMC-FPC 


CFP 


SHAW 


7777777 


W360 


EMERGENCY MED 


EMS 


BLAKE 


6666666 



The field names are printed across the top of the screen, in the order given in the 
program command. The specified fields for each applicable record are displayed 
beneath the corresponding field title. The analyst can program the review screen to 
allow the user to change certain data or prevent the user from making any changes 
while reviewing the database information. Review screens used throughout the system 
are similar in format. The specific fields required for display for each review are 
described within the detailed requirements for the applicable system. As with 
generated screen inputs, analysts can easUy update review screens to meet user 
requirements during prototyping. 

3. Requirement Analysis Constraints 

The detailed analyses which follow describe the data structures, menus, 
inputs, outputs, and user interactions for each of the systems under consideration. 
Many of the tables and graphs produced by the systems require extensive data 
manipulations and in some cases, interaction with more than one software package. 
The design of the detailed programming for these data manipulations and extractions 
is beyond the scope of this thesis and is therefore not included in the detailed system 
requirements. The output examples were generated using sample data similar to that 
which would be extracted from the database. Where applicable, the program listings 
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for each system contain comment statements indicating where data manipulations and 
report generation would have to occur to produce the desired output. Within the 
system requirements is a detailed description of the data elements necessary to create 
the outputs. The actual method of output generation will depend on the software 
packages used. For example, if the database software has graphing capability, the 
graphs can be generated internally from the existing data. If not, the data will have 
to be moved to a separate graphics software package to produce the desired graphs. 
These software specific constraints are not included as part of the requirements analysis 
but would have to be considered further in the development life cycle, once the design 
and software selections have taken place. 

D. DETAILED REQUIREMENTS 

1. Budget Information System (see Program, Appendix C) 

Figure 23, a user concept diagram, gives a picture of the components of the 
new budget information system. The user concept diagram, as discussed in the previous 
section, allowed us to give the Department Chief a general picture of the new 
requirements necessary for the budget information system. 
a. Data Structures 

To successfully meet the needs of the Department Chief, the data 
structure for the budget system was designed to provide maximum flexibility in data 
retrieval and analysis. Each database was designed to represent a portion of the budget 
process, e.g., the receipt of the quarter’s budget allocations or the receipt of the 
section’s expenditures as reported in the month end report. Figure 24 represents how 
each database relates with the other databases in the budget information system. 
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Figure 23. Budget Information System User Concept Diagram 

The structure of the data fields facilitates the combination of databases 
through the use of relationships among the key fields between the databases. The key 
field identified throughout the budget databases is the Account Processing Code (APC) 
which is used within the hospital for financial accounting purposes. 

The APC database contains the following data fields: 

• Account Processing Code. Hospital-wide funding code. 

• Section Description. This is the specific department name associated with a 
particular APC code. 

• Section Code. This field was designed to represent the true organizational 
structure of the department. It allows the system to interrelate sections along 



97 



organizational lines versus the artificial budgetary lines necessitated by the 
APC funding codes. This convention allows other subsystems of the DI^CM 
information system to relate budgetary information along the same command 
lines, such as is necessary in the Productivity system. The codes used in this 
field include: 

DEP Department Headquarters 

FPC Family Practice Clinic, Main Hospital 

CFP Family Practice Clinic, Troop Qinic 

GOC General Outpatient Qinic 

EMS Emergency Medical Services 

POM Presidio of Monterey Health Clinic 

CTM Consolidated Troop Medical Clinic 

FHL Fort Hunter Liggett Qinic 

AMB Ambulance Section 

FSO Flight Surgeon Office 

• Point of Contact for budget matters within the section. 

• Telephone Number. Self Explanatory. 

• Status Code. A system code, either "A" for active, or "I" for inactive. This 
code is needed to allow APCs which are no longer in use (identified by an 
I) to continue to be linked with budget data to maintain long term historical 
APC information. The APC code, once entered into the system, is never 
deleted. Only active APCs (coded A) are displayed when a user requests an 
APC listing. 

The APC Allocation Database contains the following fields: 

• APC code. Described above. 

• Fiscal Year (FY). 

• Quarter. The quarter of the given fiscal year. 

• Allocation: The funds allocation for the APC in the first field further 
delineated by the Fiscal Year and Quarter fields. 

The APC Monthly Expenditure Database contains the following fields: 

• APC code, as described earlier. 

• Fiscal Year of expenditure. 
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• Month of expenditure. 

• Quarter of expenditure, computed from the month field, i.e., if month is 10, 
quarter is 1. 

• Expenditure for the month. 



APC INFORMATION DATABASE 




MONTHLY EXPENDITORE DATABASE 



Figure 24. Budget Information System Data Structures 
b. Data Inputs 

The user will be required to maintain the databases discussed above 
through three database interfaces. The three interfaces are: 

• Enter or delete quarterly allocations. 

• Enter or delete monthly expenditures for each section. 

• Enter or change the status of a section’s APC information. 

The menu hierarchy chart is depicted in Figure 25. As discussed in the 
previous section of this chapter, the user is required to enter the fiscal year to limit the 
database search. If necessary, the month or quarter within the selected fiscal year is 
also entered. These entries are standardized as discussed in Section C, General 
Requirements. AU entries within a particular menu cycle are restricted to the user’s 
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chosen fiscal year. This restriction is desired because most data entries will require the 
same fiscal year since the user usually works in one fiscal year at a time. To change 
fiscal year whUe working in the selected menu, the user must return to the main menu 
and enter the new fiscal year when prompted. The entries within the selected menu 
cycle are limited to the chosen fiscal year so the user does not have to re-enter the 
fiscal year for each additional expendinire or similar input. 

In the cases where the APC is entered by the user, the system verifies 
the code entered against the active APC information database and, if the APC is found, 
confirms the user’s choice with the following screen. 

Point of Contact; TeiephoneiHHj^HIH 

This confirmation prevents the entry of either a wrong or inappropriate APCs that 
would destroy the integrity of the allocation and expenditure databases. If the APC is 
not found, an appropriate warning is issued to the user and he or she is allowed to 
try again. 



Figure 26 is a picture of the user input screen used for the entry and 
deletion of a quarter’s budget allocation for a given APC. The fiscal year, APC, and 
quarter have already been entered by the user and will appear on the input screen. 
This screen is modified when used in the deletion process by the addition of a 
comment. Delete this Record? (Y/N) g , at the bottom of the screen. 

Figure 27 depicts the user input screen that allows the user to enter the 
monthly expenditures for a particular APC. As discussed previously, the user can only 
enter the actual allocation for the month. The month and APC have already been 
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BUDGET SYSTEM 

Section I 



MAIN 

MENU 



CONTfNU€D, SECTION 2 



UPDATE 
FISCAL YEAR 
ALLOCATIONS 



UPDATE 

MONTHLY 

EXPENDITURES 



ADD 

ALLOCATIONS 



ADD 

EXPENDITURES 



CHANCE 

ALLOCATIONS 



CHANCE 

EXPENDITURES 



REMOVE 

ALLOCATIONS 



REMOVE 

EXPENDITURES 



REVIEW 

ALLOCATIONS 



REVIEW 

EXPENDITURES 



BUDGET SYSTEM 
Section 2 




Figure 25. Budget Information System Menu Hierarchy Chart 
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entered and verified to be correct. This format, modified like the quarterly format, is 
also used for verification prior to the deletion of a record. 




Figure 26. Quarterly Budget Allocation Input Screen 



Enter the Monthly Expenditure 



APC Code 


W-156 




Month 


10 




Expenses 







Figure 27. Monthly Expenditure Input Screen 

Figure 28 depicts the user input screen that allows the user to enter or 
change an APC. The entry of a new APC is preceded by verification that the APC 
requested is not in the current database. If the requested APC is found in the existing 
database, the user is warned and allowed to try again. The user is not allowed to 
reenter the APC once the screen in Figure 28 is presented. This prevents redundancy 
in data entry and keeps the user from circumventing the duplicate APC check 
procedure. The section codes are displayed on the screen to facilitate user entries. 
Inactivation of the APC is allowed when the user is prompted with "Do you wish to 



102 



puf this APC info inactive status? (Y/N) | If the user wants to change a 
particular APC’s status code to inactive, the APC record is automatically annotated 
with the new status code. Activation to an active status is automatic when the user first 



enters a new APC. 





APC Code Entered -> 


W'140 




SECTION 


Point of Contact HRR 
Telephone Humber (HR) 


Section Code 


m 













SECTION 


CODES 




Family Practice Clinic 


FFC 


Consolidated Troop Clinic 


CTM 


General Outpatient Clinic 


GOC 


Fort Hunter Liggett Clinic 


FHL 


CTMC-Family Practice 


CFF 


Ambulance Section 


AI-IB 


Emergency Medical Service 


EMS 


Flight Surgeon Office 


FSO 


Presidio of Monterey 


POM 


Department 


DEP 



Figure 28. APC Information Input Screen 
c. Outputs 

Outputs are divided into two general categories. Review screens 
(discussed in Section B of this chapter) and pre-formated reports. The three general 
review screens presented to the user are depicted in the menu hierarchy chart in Figure 
25 as the menu options either to review allocations, expenditures, or all of the APC 
information. Each review option provides the user with the generic review display 
as described in Section B of this chapter. TTie data fields presented in each case are 



the complete data fields of the respective active database. 



(1) Monthly Budget Expenditure Report. Figure 29 is an illustration 
of the monthly budget expenditure report. This report serves as the Department Chief’s 
indicator of the month to month status of the department’s budget. This report is 
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critical to the monitoring of the section’s compliance with the department’s budget. 
This report is also provided to the section chiefs for the same reason. 

The user is prompted to enter the fiscal year and month desired 
prior to the output of this report. The databases and appropriate fields necessary to 
create the report are listed below. 

• APC, extracted from the Monthly expenditure database. 

• Section Description. This information is obtained from the combination of the 
APC database with the Monthly Expenditure database to obtain the title for 
each APC in the monthly expenditure database. 

• Allocation for the quarter. The APC’s allocation figure from the allocation 
database is combined with the monthly expenditure database for the selected 
fiscal year and quarter. 

• Expenditures for the month. This data is derived for each APC from the 
monthly expenditures database. 

The following numbered items, which clarify the calculated fields 
within the report, correspond with the numbers in Figure 29. 

1, This is the fiscal year of the report. 

2 This is the month of the report. The numerical month requested is converted 
to the name of the month, i.e., month 10 becomes October. 

3 Quarter of the report. 

4 Report date provided by the system. 

5 Spent for Quarter. This field is calculated by summing all the monthly 
expenditures for the specified quarter. For instance, if the monthly report is for 
November, the system searches the monthly expenditure database and finds aU 
expenditures for the first quarter’s months; October, November, and December. 
(Note: in this example, December’s expenditures would be zero.) 
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W140 PRIMARY CARE 4000.00 3000.00 75 % 1333.33 36.36 
W357 FAM PRAC CL 9000.00 9500.00 ** 106 % 3000.00 3100.00 
W360 EMERG MED SERVICE 30000.00 5000.00 17 % 10000.00 11000.00 

(i) ^ (i) 't' 




DEPARTMENT TOTALS 



43000.00 I 17500.00 



41 % 



14333.33 



14136.36 



99 % 



** Indicates an overexpendituie ot funds . 

Figure 29. Monthly Budget Expenditure Report 



6 Flag Field. This field prints a "**" if the amount spent for the quarter or 
month exceeds the amount allocated for the quarter or month (see Note 8 below). 
This flag serves as a visual indicator to the reader and highlights probable 
problem areas. 



7 Percent Spent for Quarter. This field is computed by dividing the amount 
expended so far in the quarter (as determined in Note 5 above) by the allocation 
for the quarter. 

8 Funds per Month. This amount is computed by dividing the quarterly 
allocations by three to provide monthly allocations for the sections. 



9 Percent Spent for Month. This field is computed by dividing the amount 
expended during the month in question by the Funds per Month (explained in 
Note 8 above). 



(2) Quarterly Report. Figure 30 is an illustration of the quarterly 
budget expenditure report. This report serves as the Department Chiefs indicator of the 
status of funds for the selected quarter. This report, like the monthly report, is critical 
in allowing the Department Chief to monitor the sections’ compliance with the 
department’s budget. TTiis report is also provided to the section chiefs for the same 



reason. 



The quarterly report is designed to closely resemble the monthly 
report. This report remains in the same format as the monthly report, but excludes all 
the fields relating to monthly expenditures. 

The user is prompted to enter the fiscal year and the quarter desired 
prior to the output of this report. The fields required for each record are the same as 
described in Subsection (1) on the monthly budget expenditure report. 



d- 





Department 

Quarterly 


of Family Practice 
Expenditure Report 






Montn 


JULY 




Fiscal Year 


89 


^Quarter 3 




Report Date 


07/20/ 89^ 


APC INFORMATION 


QUARTER 


APC 


SECTION 


ALLOCATED 


SPENT 


★ ★ 


PERCENT 

SPENT 



W140 PRIMARY CARE 
W357 FAM FRAC CL 
W360 EMERG MED SERVICE 



4000.00 

9000.00 
30000.00 



3000.00 

9500.00 ** 

5000.00 f 

1 J 

0 0 



75 % 
106 % 
17 % 



\ 

0 



0 - 



DEPARTMENT TOTALS 



43000.00 



17500.00 



41 % 



** Indicates an overexpenditure of funds. 



Figure 30. Quarterly Budget Repon 

The following numbered items, which clarify the calculated fields 
within the report, correspond to the numbers in Figure 30. 

1. This is the Fiscal Year of the report. 

2 This is the quarter of the report. 

3 Report date provided by the system. 

4 Spent for Quarter. This field is calculated by summing all the monthly 
expenditures for the requested quarter. For instance, the system searches the 
monthly expenditure database and finds all expendimres for the selected quarter’s 
months, for each ARC. 
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5 Flag Field. TTiis field prints a "**" if the amount spent for the quarter exceeds 
the amount allocated for the quarter. TTiis flag serves as a visual indicator to the 
reader and highlights probable problem areas. 

6 Percent Spent for Quarter. This field is computed by dividing the amount 
expended so far in the quarter (as described in Note 4 above) by the allocation 
for the quarter. This process is repeated for each APC. 

(3) Fiscal Year Allocation Report. Figure 31 is a representation of 

the Fiscal Year Allocation Report. This report shows the allocation for each APC for 

each quarter in the user selected fiscal year. This report also shows the percent change 



between the previous fiscal year’s allocation and the selected fiscal year’s allocation. 
This report provides the Chief with a quick look at the relative allocations for each of 



his sections compared with fund allocations from the previous fiscal year. 

FISCAL YEAR ALLOCATION REPORT 
FY 89 




W357 FAM PRAC CLINIC 14000.00 -0.11 8000.00 -0.50 8000.00 -0.50 8000.00 -0.50 38000.00 -0.40 

W358 CTMS-FPC 10000.00 1.77 6000.00 1.06 6000.00 1.06 6000.00 1.06 28000.00 1.24 




The user is prompted to enter the fiscal year prior to the output 



of this report. The fields required for output of this report include: 

• APC. 

• Section Description. 
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• Allocations. For each APC for the current year. 

• Allocations. For each APC for the previous year. 

The following numbered items, which clarify the calculated fields 

within the report, correspond with the numbers in Figure 31. 

1_ This percentage reflects the percent change between the previous fiscal year’s 
allocation and the currently selected fiscal year allocation. 

2 Totals for the department. Tin's number reflects the total allocation for the 
department for each quarter in the selected fiscal year. This figure is calculated 
from totaling all quarter allocations for all of the APCs within the APC 
Allocation Database. 

3 In the cases where an APC did not exist in a prior year, the percentage change 
field (as described in Note 1) is left blank. 

(4) Fiscal Year Recap. Figure 32 provides an illustration of the Fiscal 
Year Recap Report. This report serves as the Department Chief’s indicator of the year’s 
funds status for the department. This report is critical in allowing the Department Chief 
to analyze each section’s compliance with the imposed funds limitations. Throughout 
the year, this report can provide a quick look at the current status of funds remaining 



to fulfill the needs for the rest of the fiscal year. 



Department of Family Practice 
FISCAL YEAR RECAP REPORT 



Fiscal Year : 89 Report Date : 7 /20/89 



APC INFORMATION || 


FISCAL YEAR 


89 


PXCAF 


APC 


SECTION 1 


ALLOCATED 


SPENT 


# it 


PERCENT 

SPENT 


UNDER COMMITTED 
THIS FY 


OVER COMMITTED 
THIS FY 



W140 PRIMARY CARE 16419.00 1091.43 6 % 15532.57 




** Indicates an overexpenditure of funds . 

Figure 32. Fiscal Year Recap Report 
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The user is prompted to enter the fiscal year desired prior to the 
output of this report. The fields required for output of this report include: 

• APC. 

• Section description. 

• Allocation for the quarter. 

• Expenditure for the month. 

The following numbered items, which clarify the calculated fields 
within the report, correspond with the numbers in Figure 32. 

1 Allocated Funds for FY. This number represents the allocation for each APC 
in the allocation database for the selected fecal year. This number is computed 
by totaling aU quarter’s allocations within the selected fiscal year for each APC. 

2 Total Spent this FY. This represents the total amount spent in the selected 
fiscal year for the APC . This number represents a total of all monthly 
expenditures for the selected fecal year in the monthly expenditure database. 

3 Uncommitted Funds this FY. This number represents the difference between 
Allocated Funds for FY (Note i) and Total Spent FY (Note 2). 

4 Over Committed this Fiscal Year. This column is printed when the 
uncommitted funds are negative in the preceeding column (Note 3). It serves to 
flag overcommited sections within the department. 

5 Percent Spent FY . This column is calculated by dividing the Total Spent this 
FY figure (Note ^ by the Allocated Funds for FY figure (Note i). 

6 Department Totals. These numbers, with the exception of Percent Spent (Note 

are totals of the resjjective column above the numbers. The Percent Spent 
figure is the total spent for the fiscal year divided by the total allocated funds. 

(5) Percent Spent For Quarter Graph (see Figure 33). This report 

provides the Department Chief with a graphical portrayal of the funds remaining for 

each APC for a selected quarter. This graph provides a visual picture of the current 

status of all of the APC’s expenditures. 
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Department of Family Practice 

Percent Spent for Quarter 



APC SECTION 

PRIMARY CARE 
FAM PRAC CL 
CTMC-FPC 
EM8 
FSO 
QOC 
POM-HC 

r'Tiuir' 

BN AID STATION 
FHL-HC 
CTMC (PATH) 
CTMC (RAD) 
CTMC (PHARM) 
AMB SVC 
CTMC (IMMUN) 
BN AID STAT (IMMUN) 
DEPARTMENT 





20% 40% 60% 80% 100% 120% 140% 



PERCENT SPENT 



) 



Figure 33. Percent Spent for Quarter Graph 



The user is prompted to enter the fiscal year and quarter desired 



prior to output of this report. This report requires the following fields to be completed: 

• APC. 

• Section description. 

• Total Expenditures for the quarter for each APC 

• Allocation for the quarter for each APC . 



The following numbered items correspond to the numbered items 



in Figure 33; 



I The X-axis represents the APC’s expenditures for the quarter on a scale from 
0 to 100 percent of the amount allocated for the section. 



no 



2 The actual computation of this percentage comes from dividing the total 
expenditures for a section by the allocation for that section. 

3 APC’s active in the selected quarter are reported along the Y-axis. 

(6) Trend Analysis Graph (see Figure 34). These two graphical pictures 
provide the Chief with a look at the current trend in expenditures for the current year 
and the trends for the two previous years. The expenditures are compared to the 
allocations for the respective fiscal years. This report will be used to report and track 
the overall budgetary trends within the department for the current fiscal year. This 
report can be called up at any time during the current fiscal year. 

The user is required to enter the fiscal year prior to output of this 
report. The data fields necessary to create this report include: 

• Total Allocation for all APCs for each quarter within the selected fiscal year. 

• Total expenditures for all APCs for each month within the selected fiscal year. 
This will not be graphed but serves as the building block for the graphing of 
this data on a cumulative basis. 

A calculated cumulative total for each of the above data fields is 
required to create these two graphs. As depicted in Figure 34, one line is graphed to 
represent the cumulative total of each quarter’s allocation. The second line represents 
the cumulative total expenditures for each month. 

The following numbered items correspond with Figure 34. 

_1 This line reflects the cumulative total for the total allocations for aU APC’s 
reported for the selected fiscal year in the APC Allocation Database. 

2 Each tick mark on the line corresponds to the actual total expenditure for all 
APCs for the given month on the X axis. 
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Figure 34. Trend Analysis Graph 
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3 This graph represents a long term trend analysis of department wide 
expenditures. The system uses the current fiscal year’s expenditures and the two 
previous year’s expenditures to create this graph 

4 The fiscal year of the information graphed. 

5 Quarter allocations are plotted on the FY graph by dividing the quarterly 
allocation into three equal monthly allocations (done within the department). 
These monthly allocations are then graphed on a cumulative basis. 

6 The percent of allocation is computed by dividing the expenditures for the 
month by the allocation for the month. 

2. Equipment Information System (see Program, Appendix D) 

Figure 35 is the UCD describing the proposed Equipment Information 
System. As shown in the diagram, initial equipment requirements are identified with 
the department’s Resource Information Report (RIR). The RIR is shown in Figure 36. 
This report is completed by the sections and submitted to the department NCOIC. In 
addition to new equipment requirements, the RIR is also the medium for updating 
previously submitted equipment requirements. The information contained in the RIR 
is used by the department to update the equipment procurement database. As shown 
in Figure 36, the RIR is also the medium for collecting section personnel information, 
i.e., gains, losses, and changes. The personnel portion of the RIR is discussed in 
Section 3, Personnel System. 
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Figure 35. Equipment Information System User Concept Diagram 
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Figure 36. Resource Information Report (RIR) 
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Approved 



a. Data Structures 



The Equipment System consists of two databases. The primary database 
maintains the active department equipment requirements and contains the following data 
fields: 



• Equipment Code Number. This number, assigned by the system, uniquely 
identifies each equipment item in the database. 

• Section Code. Explained in Section 1, Budget System. 

• Date of Request. The date equipment is requested by the section. 

• Item Description. This is a short description of each equipment item identified 
in the database. 

• Type of Request. The equipment requested will be one of four types, 
MEDCASE, CEEP, CAPR, or other as described in Chapter IV. 

• Priority. The priority number is a ranking of all of the equipment to indicate 
the relative priority of each. The Department Chief assigns the priority to all 
department equipment using the priority worksheet described in the Outputs 
section below. 

• Urgency Code. The urgency code indicates how soon the equipment is needed 
by the section. 

• Quantity. 

• Unit Price. 

• Extended Price. Quantity * Unit Price. 

• Status of Procurement. The status of the procurement is indicated by one of 
five codes to show where each equipment request is in the procurement 
process. The five codes and their meaning are listed below: 

PW Paperwork is being prepared by the section requesting the equipment. 
RM RMD is processing the equipment request. 

AP RMD has approved the equipment procurement. 

00 The section as put the equipment on order. 

RC The equipment has been received by the section. 

• Comments. 
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The second database maintains the historical information on equipment 
previously procured by the department and consists of the following data fields: 

• Section Code. 

• Item Description. 

• Type of Request. 

• Quantity. 

• Extended Price. 

• Date of Request. Taken from primary database described above. 

• Transfer Date. The date the item was transferred to the historical database 
(upon receipt of the equipment). 

• Months to Complete Procurement. The difference between the date of request 
and the transfer date. 

• Comments. 

b. Data Inputs 

The Equipment System menu hierarchy chart is shown in Figure 37. 
The menu system allows the user to update the equipment database, print reports, and 
archive completed equipment procurements in the historical database. Users enter new 
equipment requirements into the primary equipment database using the input screen 
shown in Figure 38. This screen presents all of the data fields necessary for user input 
and displays the various codes needed for the specific data fields. 

To change or remove equipment from the database, the user selects the 
appropriate menu item and is then prompted to enter the equipment code number or 
the section code to identify the equipment to be changed or removed. If the user does 
not know the equipment code number, he or she can enter the section code. A list 
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EQUIPMENT SYSTEM 
Section 1 




Section 2 




Figure 37. Equipment Menu Tree 
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of all equipment requirements for that section is presented. The user is then asked to 
enter the record number (displayed to the left of each equipment item) of the desired 
equipment record to change. When changing equipment data, the user is presented 
with the same screen discussed above for new data entry. 



ENTER NEW EQUIPMENT DATA 



EQUIPMENT CODE # 



SECT DATE 



ITEM DESCRIPTION 



TYPE 



URGENCY 

■ 



QTY 



UNIT PRICE 



STATUS CODE 



COMMENTS 



URGENCY CODES 


0 


Needed Now 


1 


1 Year 


2 


2 Years 


3 


3 Years 


4 


Not Urgent 



TYPE OF 


REQUEST CODES 


MEDC 


MEDCASE 


CEEP 


CEEP 


CAPR 


CAPR 


OTHE 


OTHER 



STATUS CODES 



PW Paperwork 
RM RMD Process 
AP Approved 
OO On Order 
RC Received 



Figure 38. Equipment Input Screen 

The user is allowed to update the priorities on the equipment list. 
Priority changes are obtained from the priority worksheet (discussed in the Output 
section below). The Department Chief reviews all equipment requests and completes 
the priority worksheet to identify overall department priorities. The database is then 
updated with the new priorities. After selecting the equipment, the user is presented 
with a review screen similar to that described in Section C of this chapter. The fields 
displayed correspond to the priority worksheet to simplify user input and are listed 
below: 

• Equipment Code Number. 

• Type of Request. 

• Section Code. 
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• Item Description. 

• Urgency Code. 

• Priority. The Department Chief’s numerical ranking for the item. 

• Quantity. 

• Unit Price. 

The user is allowed to enter the changes directly to the review screen. 
When equipment status changes, e.g., an equipment requisition is submitted or 
equipment is received, the sections are required to indicate this on the RER and submit 
it to the department NCOIC. These status changes are then entered into the database 
using the input screen shown in Figure 39. This screen is similar in format to the 
Status Update section on the RIR to simplify user data entry. 



1 SECTION FPC 


EQUIP CODE 
9010.01 


ITEM DESCRIPTION QTY 

BREAST PUMP 2 


U14IT PRICE 
1300.00 


STATUS 

PW 




COMMENTS 







Press ESC to abort editing, ENTER to complete changes. 



Figure 39. Status Ujxiate Screen 
c. Outputs 

(1) Review Equipment List. The format of the review screen is 
discussed in Section B above. All of the equipment database fields are listed on the 
review output screen. The user can scroll left and right, up and down, to view or 
change all fields for each record. 
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(2) Department Equipment Report (see Figure 40). The department 



e(|3ipment report is a complete equipment requirements listing for the department. All 
of the fields in the equipment database are used to produce this report. The user is 
albwed to choose one of three sort options. The flexibility to select the sort option 
mikes it easier to highlight those aspects of equipment procurement most important to 
the Department Chief. Each sort option is discussed below: 

• Sorting by Cost. The equipment list is sorted by the extended price field, 
from high values to low. 

• Sorting by Urgency. The equipment list is sorted by the urgency code, from 
zero (0) for immediate equipment requirements to four (4) for non-urgent 
requirements. Within each urgency code section the equipment is further 
sorted by section code and extended price (from high to low). 

• Sorting by Status. The stams sort option groups the equipment information 
by each of the five stams codes. Each group is further sorted by section code 
and extended price (fi-om high to low). 




TSi 

cmz 


SECT 


REQ 

DATE 


DESCRIPTION 


TYPE 

REQ 


PRI 


ORG 


QTY 


UNIT 

PRICE 


EXTENDED 

PRICE 


ACCUMULATED 

TOTALS 


STAT 


COMMENTS 


90U\01 


TFC 


01/10/89 


BEDPAN 


ME DC 


2 


1 




5200.00 


10400.00 


10400.00 


FW 




9025.20 


EMS 


01/20/89 


SPIT CUP 


OTHE 


5 


2 


5 


1000.00 


5000.00 


15400.00 


oo 


BACKOPD 


836r..89 


CTM 


12/15/88 


MICROCOMPUTER 


CAPR 


9 


1 


1 


3000.00 


3000.00 


18400.00 


oo 


BACKORD 



910r. 60 CFP 04/10/89 GAMMA CAMERA CEEP 4 1 1 1000.00 1000.00 19400.00 AP 



40 and explain certain portions of the report. 

1 The system date is printed at the top of the report. 

2 The type of sort indicates how the equipment list has been sorted, by COST, 
URGENCY, or STATUS. 

5 The format of the fields listed across the top remains the same regardless of 
the sort option chosen. 




Fij^re 40. Department Equipment Report 



The following numbered items corresp>ond to the numbers in Figure 
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4 TTie cumulative total is calculated by adding each successive extended price to 
the previous cumulative total. 

(3) Equipment Type Report (see Figure 41). The equipment type 
report is a listing of the equipment requirements for one of the equipment types, either 
MEDCASE, CEEP, CAPR, or OTHER. The user selects the type of equipment he or 



she wants listed from the menu. All of the fields in the equipment database are used 



to produce this report. The user is allowed to choose one of two sort options. Each 



sort option is discussed below: 



• Sorting by Cost. The equipment list is sorted by the extended price field, 
from high values to low. 



• Sorting by Priority. The equipment list is sorted by the priority code, from 
one for highest priority to the lowest existing priority in the database. Within 
each priority section the equipment is further sorted by section code and 
extended price (from high to low). 



TYPE EQUIPMENT 



* — 

: CEEP^^V 




EQUIPMENT TYPE REPORT 




DATE: 7/25/89 
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DATE 
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33750.00 


oo 


BACKORD 
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CTM 


12/15/88 


FLURO-LITE 
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1 
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1149.00 
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oo 


BACKORD 
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CFP 


04/10/89 


PLASMA BATH 


1 


1 


1500.00 


1500.00 


36399.00 


AP 








Figure 41. Equipment Type Report 



The following numbered items correspond to the numbers in Figure 



41 and explain certain portions of the report. 



1 The system date is printed at the top of the report. 



2 The type of equipment indicates which equipment type is listed in the report, 
either MEDCASE, CEEP, CAPR, or OTHER. 

3 The format of the fields listed across the top remains the same regardless of 
the sort option chosen. 

4 The cumulative total is calculated by adding each successive extended price to 
the previous cumulative total. 
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(4) Equipment Priority Worksheet (see Figure 42). The priority 



worksheet is used by the Department Chief in a meeting with each of his section 



chiefs. In this meeting, the priority of all of the department’s equipment requirements 



is determined and annotated on the priority worksheets for each equipment typ>e. These 



worksheets are then used to update the priorities in the equipment database. 



Typ«» OTHERS 
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2500.00 


2500.00 
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2 
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ENDOSCOPE 


99 


4 


1 


500.00 


500.00 





"□pdat «dT^*qulrem«nt3 



Coiwnants 




Figure 42. Equipment Priority Worksheet 



The data fields necessary to produce the priority worksheet are 



listed below: 



• Type of Equipment. 

• Equipment Code Number. 

• Section Code. 

• Item Description. 

• Priority. 

• Urgency Code. 

• Quantity. 

• Unit Price. 

• Extended Price. 



• Comments. 



The following numbered items correspond to the numbers in 



Figure 42 and explain certain portions of the report. 
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1 The system date is printed at the top of the report. 

2 The type of equipment indicates which equipment type is listed in the repon, 
either MEDCASE, CEEP, CAPR, or OTHER. 

3 A fill in section is provided to allow the Department Chief to enter the updated 
priorities. 



(5) Equipment Historical Report (see Figure 43). Once equipment 
is received, the data referencing it can be archived from the primary equipment 
database to the historical database. All of the historical database fields are used to 
produce the equipment historical report. The report can be sorted either by section or 
by equipment type. Within each of these sort options the list is further sorted by the 
extended price field, from high to low. 
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1 


1000.00 


11/12/88 


02/12/89 


4 



Subtotals 1000.00 1 



Figure 43. Equipment Historical Report 

The following numbered items correspond to the numbers in 
Figure 43 to explain the repon information. 

1 The transfer date is automatically entered into the database using the system 
date when the data is archived. 

2 The months to complete the procurement are calculated by subtracting the 
transfer date from the original request date. 

3 Subtotals for each section or equipment type group are shown for the extended 
price field and is obtained by totaling the extended prices for the respective 
group. 
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(6) Historical Summary Report (see Figure 44). The historical 
summary report displays summary statistical information about the data in the historical 
database. The Department Chief can use the summary report to determine the 
department’s history of equipment procurement in terms of the number of equipment 
requests, average costs of the equipment requested, the type of equipment requested, 
and the average length of time to obtain equipment. The historical database fields 
necessary to create the summary report are listed below. 

• Section Code. 

• Type of Request. 

• Quantity. 

• Extended Price. 

• Date of Request. 

• Transfer Date. 

• Months to Complete Procurement. 

The following numbered items correspond to the numbers in 
Figure 44 and explain the method used to produce the summary report information. 

1 The earliest date of request and the latest date of request contained in the 
database are listed at the top of the report. 

2 The total number of requests for each type of equipment are calculated by 
adding the total quantities of equipment procured for each equipment type. 

3 The average cost of each equipment type is calculated by dividing the total 
extended price for the equipment type group by the total number of requests for 
that equipment type group. 

4 The average time to complete an equipment procurement is calculated by 
averaging all of the figures for the number of months to complete each 
procurement for each equipment type. 
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5 The total number of requests for each type of equipment is summed for each 
section. 

6 The average cost for each type of equipment is calculated for each section by 
dividing the total cost of the equipment type requests for a section by the totd 
number of requests for that equipment type for the section. 



HISTORICAL SUMMARY REPORT 
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Figure 44. Historical Summary Report 

3. Personnel Information System (see Program, Appendix E) 



Figure 45 is the user concept diagram for the personnel information system. 



This system interfaces the four major personnel subsystems identified in Chapter IV. 



These information subsystems include; 



• Department Personnel Information Subsystem (including personal data). 

• Table of Distribution and Allowances Subsystem. 

• Leave and Absence Recordkeeping Subsystem. 

• Continuing Medical Education (CME) Budget Subsy.stem. 
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Figure 45. Personnel Information System User Concept Diagram 
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The consolidation of all four personnel subsystems under one major system 
simplifies the transfer and maintenance of the six data files necessary to maintain the 
data. All personnel inputs, processing, and outputs are captured within a single series 
of operations without requiring the user to leave the current application environment. 
a. Data Structures 



Figure 46 depicts the various database files required to support the 
personnel information system. This figtire shows how the file that represents a person 
within the department serves as the pivotal point for the interrelation of all of the 
personnel files. 



PERSOlWEL DATABASE 




Figure 46. Personnel Data Structures 
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The key field identified throughout the database is the Personnel 
Identification Code as described below. This code is already used in the current system. 
It is recognized as the method by which personnel data should be maintained 
throughout the department. 

The personnel file, which represents an individual assigned to the 
department, contains the following fields: 

• Personnel Identification Code. This code is derived from the first letter of an 
individual’s last name, combined with the last four numbers of their social 
security number. 

• Last Name. 

• First Name and Middle Initial. 

• Rank. 

• Branch of Service (accepted military abbreviations e.g.. Medical Corps (MC), 
Army Nurse Corps (AN), etc.). 

• Military Occupational Specialty Code. 

• Arrival Date within the Department. 

• Anticipated Date of PCS (if known). 

• Currently assigned TDA Paragraph Number. 

• Currently assigned TDA Line Number. 

• Currently assigned TDA Position Number. If the person is carried as excess, 
this number will be 99. 

• Doctor Status (if appropriate). This code serves to track only the current 
training status of doctors in the residency program. The codes used are; (1) 
Third Year Residency, (2) Second Year Residency, (3) First Year Residency 
(Student). 
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The personal information database file serves as the repository of 
sensitive information about an assigned individual. Each record contains: 

• Personnel Identification Code. This code serves to relate this file to the 
personnel file. 

• Local Home address. 

• City of Home address. 

• State. 

• Spouse’s first name (if appropriate). 

• Children’s names, followed by their ages (if appropriate). 

• Home telephone number. 

• Date of rank. 

• Personal Comments. 

The Table of Distributions and Allowances (TDA) database file reflects 
the current positions available as obtained from the most up to date TDA for the 
department. Each record contains the following fields; 

• TDA Paragraph Number. 

• TDA Line Number. 

• TDA Position Number. 

• TDA Official Job Title. 

• The APC that relates to this particular position. 

• The authorized branch of service of this position. 

• The authorized rank or grade for this position. 

• The authorized Military Occupational Specialty for this position. 
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• Authorized field. This field is used to determine if the position is an 
authorized position under the current TDA. This position could actually be 
required under the TDA but not authorized under peacetime conditions. This 
is a common occurrence in TDAs in the military. 

The Continuing Medical Education funds allocation database records the 
CME allocation for each fiscal year. Each record contains the following fields: 

• Fiscal Year. 

• Allocation for the fiscal year in dollars. 

The Continuing Medical Education request database records the doctors’ 
requests for CME funded education. Each doctor can have several active CME requests 
within this database. Each record contains the following fields: 

• Personnel Identification Code. 

• Fiscal Year of the request. 

• Type Request. The CME request can be one of the following types of 
requests: (C) Conference/Meeting Travel, (G) General Mission Travel, (B) 
Board Certification. 

• Start Date of Travel. 

• End Date of Travel. 

• Duration of travel. This field is computed by determining the number of days 
between the start date and the end date. TTiis data is used in the statistical 
summary reports described in Section 3.c, Outputs, below. 

• Location or Destination. 

• Purpose of travel. The title of the conference or the specific purpose of the 
request. 

• Travel Mode. Travel can either be by (A) aircraft, (P) privately owned vehicle, 
or (G) government provided ground transportation. This is used in the 
computation of the costs involved in the travel. 
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• Travel cost (Actual or estimated cost depending on the Costing Code described 
below). 

• Per Diem Cost (Actual or estimated cost depending on the Costing Code 
described below). 

• Registration Fee for the Conference (Actual or estimated cost depending on 
Costing Code described below). 

• Reimbursable expenses (Actual or estimated cost depending on Costing Code 
described below). 

• Total Cost of travel. This field is calculated by adding the Travel cost. Per 
Diem cost, Registration Fee, and Reimbursable expenses fields (Actual or 
estimated total cost depending on the Costing Code of the related fields). 

• Costing Code. This code differentiates between an estimated total cost and the 
actual costs. The actual costs are identified once the travel has been completed 
and the travel claim voucher is received by the department. 

The Absence database maintains the record of all requested leaves or 
other absences, e.g., permissive TDY, emergency leave. This database does not record 
the CME requests discussed in the CME request database section. Each record contains 
the following fields: 

• Personnel Identification Code. 

• Fiscal Year of request. 

• Type of request. (L) Ordinary Leave, (P) Permissive TDY, (E) Emergency 
Leave, (S) Sick Leave or Convalescence leave, (T) Temporary Duty, or (O) 
other type of unspecified absences. 

• Start Date of Absence. 

• End Date of Absence. 

• Duration of absence. This field is computed by determining the number of 
days between the start date and the end date. 

• Comments on special circumstances. 
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b. Data Inputs 



The Personnel Information System menu hierarchy chart is shown in 
Figure 47. This menu system allows the user to update the personnel system databases 
in the following areas: 

• Add, change or remove records in the personnel and personal database. 

• Add, change or remove records in the Table of Distributions and Allowances 
database. 

• Update the Personnel Files from information provided on the Resource 
Information Report explained in the equipment information system Section (2). 

• Add, change, or remove records in the Continuing Medical Education request 
and funds allocation databases. The user can also print the two required reports 
for CME fund monitoring. 

• Add, change or remove records from the absence database. 

The following sections describe the major data entry requirements for 
the personnel system. The common data entry requirements are described in the first 
section. This description is followed by the data input requirements for each of the 
major input submenus depicted in Figure 47. 

(1) Common Input Requirements. In most of the submenus, the user 
is required to enter a personnel identification code (PIC). The standardized entry screen 
discussed in Section C.2.a, Input Screens, is used for this input. The system then 
verifies the PIC entered against the personnel file. If the PIC is found in the database, 
the user is presented with the following confirmation screen. 



I 
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Figure 47. Personnel System Menu Hierarchy Chart 
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AIL CME REOUCST 



TraS IS THE PERSON WHOSE ID CODE IS ■Hi 
LAST NAME FIRST NAME HHIHl RANK H 

OCCUPYING TDA PARAGRAPH LINE H, POSITION ■ 
<<<<<<<<SYSTEM MESSAGE DEPENDING ON TYPE OF REQUEST»»»» 



This confirmation screen allows the user to determine if the 

requested PIC is correct. This type of confirmation prevents the user from entering a 

wrong or inappropriate PIC that would destroy the integrity of the database. If the 

identification code is not found, a warning, "ID Code not found! Press return to 

continue...", is displayed. The system then gives the user the option to search for a PIC 

by entering the last name of the person. All records with the requested last name are 

displayed as shown below and the user is allowed to pick the identification code of the 

correct person from the list. 

LAST NAMEFIRST NAME ID CODE 
SMITH JOHN E. S2356 

SMITH BECKY K. S9999 

ENTER THE ID CODE OF THE PERSON DESIRED; ^H 

An appropriate modification to this screen, if supported in the 
application program, would be the ability to select a record by highlighting the record 
desired and pressing the return key. This process would eliminate the possibility of 
keying errors being introduced by the user. 

If the user is requested to enter information on a TDA position, 
the screen shown below is presented to the user. 
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WHAT POSITION WILL THIS PERSON OCCUPY 
OR ENTER A ZERO (0) TO QUIT 



TDA Paragraph Number j^H 
TDA Line Number m 
TDA Position Number ^ 

Another feature that would enhance this input would be the addition 
of the ability to call up all TDA positions that are unoccupied. The user would then 
be allowed to select a TDA position by highlighting a particular position from among 
those depicted on the screen. This enhancement will make the following two screens 
unnecessary. 

The system then verifies the requested TDA position with the TDA 
database and if the position is found to exist in the database, the user is presented with 
the following standard TDA position screen. 

POSITION CHOSEN: 



Job Title : 

Authorized Branch ; H Authorized Grade : |||| 

Authorized MOS : Authorized Position : YES 

This screen also converts the authorized position field fi'om its coded value to the 
correct YES or NO answer depending on the contents of this field. 

In the cases where a TDA piosition is requested and is found to 
already be occupied by someone else, the warning screen shown below is presented to 
the user. 
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THE POSITION IS ALREADY OCCUPIED BY: 



Last Name : 
First Name : 
Rank : 



The user is then given the following choices. 

YOU NOW HAVE THE FOLLOWING CHOICES: 

1. MOVE THE PERSON FOUND IN THE POSITION TO EXCESS (POSITION 
CODE 99) AND THE PERSON YOU ARE WORKING WITH INTO THE 
POSITION YOU ORIGINALLY REQUESTED. 

2. PLACE THE PERSON YOU ARE WORKING WITH INTO THIS 
POSITION AS EXCESS (OVERSTRENGTH, POSITION CODE 99). 

3. TRY ANOTHER POSITION. 

ENTER YOUR CHOICE (1-3) : | 

(2) Enter, change, or remove personnel from the personnel database. 
As discussed earlier, the user is first requested to enter the identification code of the 
individual to add, change, or remove from the personnel file. In all of these cases, the 
system first checks the personnel file for the requested identification code. If the code 
is already in use, and the user is trying to enter this identification code to add a new 
person to the personnel file, the standard confirmation screen is displayed with the 
message "ID CODE REQUESTED IS ALREADY USED BY THE PERSON SHOWN 
ABOVE" and the user is prompted to try a different code. When the user is updating 
or removing someone already in the personnel file, this PIC check serves to confirm 
the identification code already exists in the file and warns the user if it is not found. 
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If the identification code is not found, the system gives the user the same options as 
described in the general input screens discussed earlier. 



UPDATE PERSONNEL 



ID CODE is W1456 



Last Name 


First Name MI 


RAJIK 


BRANCH 


MOS 








■ 





Arrival Date Anticipated Date of Loss . . .|P||/|Q| 





INDIVIDUAL IS ASSIGNED TO TDA POSITION 

TDA Paragraph Number Is 250 
TDA Line Number is 10 
TDA Position Number is 99 

NOTE: If Position Number is 99, the Individual is carried as excess 

Figure 48. Personnel Input Screen Format 

If the user is adding or changing information in the personnel 
database, the system requests the new position before displaying a blank data entry 
screen format. This action allows the system to verify that the TDA position is valid 
and is not already occupied by someone else. If the position is occupied, the standard 
choice screen as discussed earlier is displayed and the user must choose an appropriate 
course of action. Once they have selected a course of action, the system then allows 
access to the personnel database. The screen depicted in Figure 48 is the standard input 
screen for personnel information. This screen does not allow the user to either change 
the identification code or the position information, thus preventing the user from 
circumventing the integrity checks already accomplished by the system. 

Once the user has entered information into the personnel file, he 
or she is given the choice to enter data into the personal file. This data entry format 
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is displayed in Figure 49. This screen inchides the privacy act statement to remind the 
user of the sensitive nature of this information. 



This la the personal information for ID CODE S7395 



PRIVACY ACT STATEMENT 

PRINCIPLE PURPOSE: To maintain personal information on individuals assigned to 
this command to facilitate counseling, emergency notification, and social 
event information. 



WARNING: This information is of a highly sensitive nature and should not be 
provided to anyone outside of the chain of command without approval. 



Telephone 



Address 

City, State, Zip Code 

Date of Rank 

Wife's Name Children's Names/Ages 

Comments 



Figure 49. Personal Information Data Entry Screen 

If the user desires to delete someone from the personnel databa.se, 
the identification code entered by the user is used to find the right record. The screen 
depicted in Figure 48 is displayed with the message, "IS THIS THE PERSON YOU 
WANT TO DELETE? (Y/N)" | ", included on the screen. This allows the user to 
confirm the information about the person they desire to delete. If the user deletes the 
person, the system then purges all the files in the personnel system which have the 
requested identification code. Several databases are affected: the personnel database; the 
personal database; the CME request database; and the absence database. 

(3) Enter, change, or remove TDA information. The user gains access 
to the TDA database by initially entering the position they desire to add, change or 
remove in the position entry format described earlier. In the case where the user is 
adding a new position, this information allows the system to verify that the TDA 
position requested does not already exist in the database. If the user is modifying an 
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already existing TDA record, this information is used to locate the record or warn the 
user that the position entered does not exist in the database. 



TABLE OF DISTRIBUTION AND ALLOWANCES 



TDA Listing 



Paragraph Number 258 



POSITION TITLE 



Line Number 



10 



Job Title 




Position Number 01 



POSITION CHARACTERISTICS 



Authorized Branch 
Authorized Grade 
Authorized MOS 



APC Code 



Position Authorized 
1*YES 0=NO 






Figure 50. Table of Distribution and Allowances Input Screen 

The system must determine the authorized status of the position. 
If the position is new to the database, the user is required to answer the prompt, "IS 
THIS AN AUTHORIZED POSITION? (Y/N) | ". If the user answers yes, the system 
automatically replaces the authorization code with a one, otherwise the code is replaced 
with a zero. If the user is modifying an already existing database, the system uses the 
existing code to ask the user if they desire to change the current authorized status to 
the opposite status. For instance, if the authorized code is zero (0) (unauthorized), the 
message, "DO YOU WANT TO CHANGE THIS POSITION TO AN AUTHORIZED 
STATUS? (Y/N) I ", is displayed. 

If the user desires to delete a position, the format depicted in 
Figure 50 is used, but it includes a message to verify if the user desires to delete the 
displayed record. If the record is deleted, the system also checks the personnel database 
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to determine if someone occupies the deleted position. If a matching position is found 
in the personnel database, the person’s TDA position information is blanked in their 
record, and the following message is displayed. 

FOUND CPT SMITH OCriTYINC; THE DELETED POSITION! 

ID CODE IS S2345 . BE SURE YOU UPDATE THIS PERSON’S 

TDA POSITION WITH A VALID TDA POSITION. 

(4) Update from Resource Information Report. This menu choice 
provides the user with the capability to directly update the personnel database with 
information provided in the Resource Information Report personnel sections. Figure 
51 depicts this input screen. The system also verifies the new position entered to 
ensure that it is not already occupied, and if it is occupied, responds with the screen 
of choices discussed earlier. 



UPDATE FROM R.I.R. REPORT 



B. CHANGES TO CTOP£NT TDA (OTHER THAN LOSSES OR GAINS) 



OLD POSITION 


NEW POSITION 1 


PARA 


LINE 


POSN 


IDCODE 


LAST NAME 


RANK 


PARA 


LINE 


POSN 1 


Pi 


■ 


■ 


mm 


mmmamamBsmm 


■i 


Pi 


■ 


■ 1 



PRESS ESCAPE [ESC) TO QDIT 



Figure 51. Update from RIR Report screen. 

When the user is updating from the personnel losses section on 
the RIR, the user must first enter the PIC. This code is verified in the manner 
discussed earlier. The system then prompts the user with. "HAS THIS PERSON 
ACTUALLY DEPARTED OR IS THIS AN UPDATE TO A PROJECTED LOSS 
DATE? (ACTUAL=0, PROJECTED=l) |." If the change is a modification of the 
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anticipated loss date, the user enters the new loss date, and the record is updated 
automatically. If the loss is an actual PCS from the department, the system invokes the 
same procedures as described for the deletion of personnel in Section (2) earlier. 

(5) Enter, change, or remove CME requests. Figure 52 depicts the 

standard input screen for the CME request. This screen is designed to match the format 

of the actual printed CME request form used. The bottom of the screen is used to 

depict whether the costs displayed are actual expended costs or estimated costs. If the 

user desires to change an already existing record, the user must first enter the fiscal 

year of the request and the PIC code of the person sought. As discussed earlier, the 

confirmation screen displays the personnel information about the selected PIC with the 

message, "IS TfflS THE PERSON YOU EXPECTED? (Y/N) |." The system then 

displays all matching records in the following format: 

RECORD NO. ID CODE TYPE START DATE END DATE 

5 S7777 C 06/07/89 07/07/89 

15 S7777 G 07/20/89 07/22/89 

ENTER THE RECORD NUMBER DESIRED : H 

The user is then prompted with, "WILL COSTS BE ACTUAL COSTS OR 

ESTIMATED COSTS? (ENTER AN A FOR ACTUAL OR AN E FOR 

ESTIMATED) The system takes the user’s response and enters the correct cost 

code into the record. The system wiU also total all travel costs and update the total 

cost of travel field in the record. 

In the case where the user only wants to ujxiate a record with the 
actual costs and selects this option in the menu, the system displays the same screen 
in Figure 52, except the user can only input the cost portions of the screen format. The 
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system then changes the cost code and totals the costs for the user prior to updating 
the record. 



j SUBJECT: AFPLICATION FOR CONFERENCE/MI SS I ON TRAVEL IN FISCAL YEAR 89 
1. Type of Travel Requested | 

C-Conf e rence/Meeting Travel G-General Mission Travel B-Board Certification 



2. ID CODE of person requesting the travel is S7396 



4. Purpose of Travel is 
6. Destination 



Leave Dates Starting Date 
Duration 0 days 



5. Registration Fee 

Mode of Travel is | 

F-FLY, G-GOVT VEH, P-POV, O-OTHER 

Ending Date H/Bl/H 



13. TRAVEL COST DIEM COST $| 

TOTAL COST OF TRAVEL $ 0.00 



REIMBURSABLES $1 



EXPENSES REFLECT THE ESTIMATED COST OF TRAVEL 



F^ure 52. Continuing Medical Education Request Data Entry Screen 

Figure 53 depicts the input screen used to add, change or remove 
the records in the CME allocation database. There is only one CME allocation for the 
department for each fiscal year. Therefore, the user is always required to enter the 
fiscal year prior to using this screen to enter the CME funds allocation. 

UPDATE CME ALLOCATION 



THE CME ALLOCATION FOR FISCAL YEAR 89 SHOULD BE 




Figure 53. CME Allocation Data Entry Screen. 

(6) Enter, change, or remove leave/absence requests. Figure 54 depicts 
the data entry screen for the absence database. Prior to using this screen, the user must 
fust provide the fiscal year of the request and PIC of the person who will be entered. 
Once the PIC is entered, it is verified against the personnel database and if it is found. 
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the standard confirmation screen is displayed with the message, "IS TTITS THE 
PERSON YOU EXPECTED? (Y/N)". 

UPDATE LEAVE OR ABSENCE REQUEST 

This is the Fiscal Year 69 Leave or Absence request for ID CODE S7396 



Type of Request || 



L. 


.Regular Leave 


E . 


.Emergency Leave 


T. 


.Other TDY, not CME 


P. 


.Permissive TDY 


C. 


.Convalescent Leave 


O. 


. Other 



Starting Date H 'H Ending Date 

Duration 0 days 

COMMENT 

Figure 54. Leave and Absence Data Entry Screen 

If the user is changing an already existing record, the system uses 

the PIC entered to display the following: 

RECORD NO. ID CODE TYPE START DATE END DATE 

5 S7777 C 06/07/89 07/07/89 

15 S7777 G 07/20/89 07/22/89 

ENTER THE RECORD NUMBER DESIRED ; H 

Since the PIC has already been verified with the confirmation screen, only the PIC 

number is displayed. The user can then choose the record desired. As discussed 

earlier, the ability to "point and shoot" to a particular record would enhance the user’s 

ability to request a particular record. The record is redisplayed in the same entry 

format depicted in Figure 54. 

With each addition or change of a record, the system automatically 
recomputes the duration field by subtracting the starting date from the ending date. This 
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constant updating insures that this field will always be updated prior to saving the 
database. 

c. Outputs 

(1) Review Screens. The review of the piersonnel, TDA, absence, and 
CME request databases are accomplished by the use of the standard review screen. 
Each review option provides the user with the generic review display described in 
Section B of this chapter. The data fields presented, with the exception of the CME 
request database and the absence database, are simply the fields existing in the 
database. The CME request database and absence database are combined with the 
personnel database to create a new temporary database that contains the name 
associated with each PIC in the databases. The additional review fields displayed with 
the already existing fields in the CME request or absence database are the Rank, First 
Name, and Last name of the person that matches the PIC field in the CME or absence 
databases. 

(2) Position Listing (see Figure 55). This report provides the Chief 
with a listing of all TDA positions within his department and the personnel assigned 
to those positions. This report is generated by combining the TDA database with the 
personnel database where the TDA position in the personnel database matches the TDA 
position in the TDA database. If no match is found, the TDA information is printed 
but with the personnel information left blank. If the person is carried as excess, their 
information is also printed but with only the TDA paragraph number, TDA line 
number, and the excess position code of 99. This report is sorted in TDA paragraph 
number, line number, and position number order whether the position is filled or not. 
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DEPARTMENT OF FAMILY PRACTICE & COMMUNfTY MEDICINE (TDA) 

11 MAR 88 

PARA UNEl POSN GR MOS BR JOB TITLE RANK/NAME AUTH STATU S 
DEPARTMENT OF FAMILY PRACTICE (PEP) 



531 


01 


01 


06 


61H00 


MC 


C, DEPT FP 


LTC 8MMMMNMM8 


531 


02 


01 


EL 


91B50 


EL 


CUNIC NCO 


MSG MHNMMMNI# 


531 


02 


99 










MSG 


531 


03 


01 


05 


00318 


QS 


SECT (T/S) 


MS. 



PARAGRAPH TOTAL AUTHORIZED :03 ASSIGNED : 04 

FAMILY PRACTICE CUNIC (FPC) 



IliED :03 ASSIGNED : 04 



532 

532 

532 

532 

532 

532 

532 

532 

532 

532 



01 

02 

02 

Q2A 

02A 

02A 

02A 

03 

03 

03 



532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 
532 sa 

PARAGRAPH 



03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

04 

05 
05A 

06 
07 
06 
09 

09 

10 
10 
10 
12 
12 
12 
88 
88 
88 
88 
88 
88 



01 

01 

02 

01 

02 

03 

99 

01 

02 

03 

Zm 

05 

06 
07 
06 

09 

10 
11 
12 

13 

14 
01 
01 
01 
01 
01 
01 
01 
02 
01 
02 
99 
01 
02 
03 
01 
02 

03 

04 

05 

06 
07 
06 

TOTAL 



05 

04 

04 

03 

03 

03 

03 

03 

03 

03 

C3 

03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

04 
03 
E6 
E6 
E5 
E5 
E4 
E4 
E3 
E3 

03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

#*• 



61H00 

61H00 

61H00 

61H00 

61H00 

61H00 

61H00 

61H00 

61H00 

61H00 

61H00 

61H00 

61H00 

61H00 

61H00 

61H00 

61H00 

61HOO 

61H00 

61H00 

66H00 

66H00 

71L30 

9IB30 

91B20 

91A20 

91A10 

91A10 

91A10 

91A10 

00679 

00679 

00679 

61H90 

61H9D 

61H9D 

61H9D 

61H9D 

61H90 

61H9D 

61M90 



UC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

AN 

AN 

£L 

EL 

EL 

EL 

EL 

EL 

EL 

EL 

QS 

GS 

QS 

MC 

MC 

MC 

MC 

MC 

MC 

MC 

MC 



PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 

PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
HEAD NURSE 
MED SURG NUR 
AOMIN SUPV 
CUNIC NCO 
MED SP 
MED SP 
MED SP 
MED SP 
MED SP 
MED SP 
EXCESS 
MED CLK (T) 
MED CLK (T) 
MED CLK (T) 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 
PAM PHYS 



AUTHORIZED : 26 ASSIGNED 




• MOCATES A «0 OAT ANTiai»ATED L099 

(1| • M tXAM nUOBICY <2) • 2M TtAM MPKCT (1| - 19T YtAM (WT U Pgrr) 



Figure 55. Position Listing Report 

The fields necessary to create this report are: 

• Section Description for each TDA Paragraph Number. 

• TDA Paragraph Number. 

• TDA Line Number. 
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TDA Position Number. 



• Authorized Grade for above TDA position. 

• Authorized MOS for the above TDA position. 

• Authorized Branch for the above TDA position. 

• TDA Official Job Title. 

• Rank. 

• Last Name. 

• Authorization Code for the position. 

• Doctor Status Code. This code reflects the current residency status of a doctor 
in the residency program. 

• Anticipated date of PCS for the person in the position. 

The following numbered items correspond with the numbers in 



Figure 55. 

1 This section title correlates to the TDA paragraph number in the TDA. 

2 This subtotal is the total authorized positions within the TDA Paragraph 
number. This is calculated by totaling the authorized position fields for each 
paragraph number. 

3 This is the number of persons assigned to a particular TDA paragraph. This 
number is calculated by counting the number of TDA positions where the name 
field is not blank within the same TDA paragraph number. 

4 If no name is associated with a TDA position, the phrase "VACANT" is 
printed in this field. 

5 The doctor status codes in the database. They are also explained in a foomote 
at the bottom of the report. 

6 The RANK, FIRST NAME and LAST NAME of the person who occupies a 
TDA position are concatenated to produce this field. 
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2 This total is the total for the department and is a total of all the TDA 
paragraphs subtotals. 

8 Personnel whose position code is designated as 99 do not have a job title since 
they are carried in an excess capacity. 

9 This flag indicates that the person listed has an anticipated loss date that 
is less than 60 days from the current system date. 

(3) Section Update Worksheet (see Figure 56). This worksheet allows 

the department to update its personnel database with new position information, changes 

or additions to the anticipated loss date field, and changes to the persormel status field. 

This report is very similar to the position listing with the exception of the following: 

• Each paragraph within the TDA is printed separately to facilitate individual 
delivery to sections. 

• There are three fill in the blank fields added to allow the section to directly 
annotate changes into the worksheet. 

This report is created from the same combination of databases 

necessary for the personnel listing, but only the following fields are needed to print 

this worksheet: 

• Section Description for each TDA Paragraph Number. 

• TDA Paragraph Number. 

• TDA Line Number. 

• TDA Position Number. 

• TDA Official Job Title. 

• Rank. 

• Last Name. 
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• Doctor Status Code for the person who occupies the TDA position. (Only 
applies to doctors in the residency program). 

• Anticipated date of PCS for the person in the position. 



SECTION WORKSHEET 

DEPARTMENT OF FAMILY PRACTICE & COMMUNrTY MEDICINE 

1 1 MAR 88 

PARA LINE POSN JOB TTPLE RANK/NAME STATUS ALOSS NAME 



FAMILY PRACTICE CLINIC (FPC) 



532 

532 

532 

632 

632 

632 

532 

632 

532 

632 

632 

632 

632 

532 

632 

632 

632 

632 

632 

632 

532 

632 

532 

632 

632 

632 

532 

632 

632 

632 

632 

632 

532 

632 

632 

632 

632 

632 

532 

532 

632 

532 

532 



01 

02 

02 

02A 

02A 

02A 

02A 

03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

03 

04 

05 
05A 

06 
or 
08 
00 
00 
10 
10 
10 
12 
12 
12 
86 
88 
86 
86 
66 
86 
88 
86 



PARAGRAPH 



01 

01 

02 

01 

02 

03 

90 

Of 

02 

03 

04 
06 
06 

07 

08 
00 
10 
11 
12 

13 

14 
01 
01 
01 
01 
01 
01 
01 
02 
01 
02 
90 
01 
02 
03 
01 
02 

03 

04 

05 

06 

07 

08 

TOTAL 



FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 

FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
HEAD NURSE 
MED SURO NUR 
AOMIN SUPV 
CUNIC NCO 
MED SP 
MED SP 
MED SP 
MED SP 
MED SP 
MED SP 

MED CLK (T) 
MED CLK (T) 
MED CLK (T) 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 
FAM PHYS 



AUTHORIZED 




07/20^ 

9W9V99 

9V9V99 

07/2V70 



0€/1Cm 



0 & 29^1 




ASSIGNED : 37 



(1) . M YEAR RES)0€NCY (2) • M YEAR REWO&CY (3) . 1ST YEAR REBtOENCY (STVOeTT) 



Figure 56. Section Ujxlate Worksheet 

The following numbered item.s correspond with Figure 56. 

1 These fields are intentionally left blank to allow the section to input changes 
to the current TDA position listing. 

2 The RANK and LAST NAME of the person who occupies a TDA position 
are concatenated to produce this field. 
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(4) Loss Report (see Figure 57). This report provides the department 
with a listing of all personnel who have an anticipated PCS date between two user 
specified dates. Prior to printing this report, the user is required to enter these dates 
to define the parameters for which this repiort will be printed. 



LOSS REPORT 

DEPARTMENT OF FAMILY PRACTICE & COMMUNITY MEDICINE 

11 MAR 89 



START DATE : 06/01/89 ^ ENDING DATE : 09/25/89 

The following personnel have expected anticipated loss dates within the 
above dates: 



RANK NAME 


SECTION 


PCS DATE 


OPT 


JOHN SMITH 


AMB 


07/01/89 


OPT 


JANE DOE 


CTM 


09/01/89 


MSG 


GERY JONES 


CTM 


07/09/89 


1LT 


WAYNE SHARPE 


FPC 


07/20/89 



Figure 57. Loss Report 

This following fields are necessary to print this report. 

• Rank. 

• Last Name. 

• Section Description for the pierson. 

• Anticipated Date of Loss. 

The following numbered items correspond with Figure 57. 

1 The date parameters for the report entered by the user. 

2 The date in this field must lie between the parameter dates established by the 
user. 
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(5) Vacancy Listing (see Figure 58). This report provides a listing 
of all TDA positions within the department that are vacant. This report provides the 
Qtief with a quick look at his personnel shortages and the current vacant p>ositions 
within the department. 

VACANCY REPORT 

DEPARTMENT OF FAMILY PRACTICE & COMMUNITY MEDICINE 
11 MAR 89 

The following TDA Positions are vacant: 



PARA LINE POSN GR MOS BR 



JOB TITLE AUTH 



FAMILY PRACTICE CLINIC (FPC) 



532 


03 


13 


03 


61H00 


MC 


FAM PHYS 


532 


03 


14 


03 


61H00 


MC 


FAM PHYS 


532 


12 


02 


03 


00679 


GS 


MED CLK (T) 




PARAGRAPH SUBTOTAL *** VACANCIES : 3—0 



EMERGENCY MEDICAL SERVICE (EMS) 

581 17 01 13 00602 GS GEN MED OFF 

581 17 02 13 00602 GS GEN MED OFF 



YES 

YES 



PARAGRAPH SUBTOTAL VACANCIES : 2 



-<D 



KOTAt 0EPAR1TWENT VACANCIES 



Figure 58. Vacancy Listing 

This report file is generated in the same manner as the position 

listing except that only the TDA piositions which do not have a matching person 

assigned to a position are printed. 

Die following numbered items correspond with Figure 58. 

\ This is a count of all authorized positions that are vacant within a given TDA 
paragraph number. This total represents the sum of the authorized field for the 
TDA paragraph. 



I 
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2 If the position is authorized (code=l), "YES" is displayed, otherwise "NO" is 

displayed. 

3 Total Department Vacancies. This total is the sum of all TDA paragraph 

subtotals mentioned in Note 1 above. 

(6) Social Roster (see Figure 59). This roster provides personnel 
within the department a roster of personal information of assigned personnel within the 
department. This roster both serves as a social listing to facilitate social gatherings and 
as an emergency notification listing for department personnel. The creation of this 
report requires the combination of the personnel database and personal database. In the 
case where there is not a match to a personnel record in the personnel database, "NO 
PERSONAL DATA" is printed in the report. 

The fields necessary to create this report are: 

• Last Name. 

• First Name and Middle Initial. 

• Rank. 

• Branch of Service. 

• Military Occupational Specialty Code. 

• Arrival Date within the Department. 

• TDA Official Job Title. 

• Section Description for each TDA Paragraph Number. 

• Local Home address. 

• City of Home address. 

• State. 

• Spouse’s first name. 
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Children’s names, followed by their ages (if appropriate). 
Home telephone number. 

Date of rank. 



SOCIAL ROSTER 

DEPARTMENT OF FAMILY PRACTICE & COMMUNITY MEDICINE 

11 MAR 89 



PRIVACY ACT STATEMENT 



DEPARTMENT OF FAMILY PRACTICE (PEP) 

LTC SMITH. JOHN R. POSN: C. DEPT FP 
BR: MC MOS: 61H00 ARR: 07/20/87 

1200 BIRDTREE LANE 

ANYWHERE STATE 99999-9999 

PHONE: (408)999-9999 

WIFE: BECKY CHILDREN: JIM/10, MIKE/4, SUE/1 

FAMILY PRACTICE CLINIC (FPC) 

LTC JONES. SUE R. POSN: FAM PHYS 

BR: MC MOS: 61H00 ARR: 07/20/88 

1200 SINGASONG ROAD 

ANOTHERPLACE STATE 99999-9999 

PHONE: (408)888-8888 

WIFE: N/A CHILDREN: BECKY JOE/1 

MAJ BURB, HERB R. POSN: FAM PHYS 

BR: MC MOS:61HOO ARR: 06/11/85 

23 CHIRPING TREE LANE 
ANYWHEREELSE STATE 99999-9999 

PHONE: (408)444-4444 
WIFE: JO CHILDREN: 




Figure 59. Social Roster 
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This report is created in the format showTi in Figure 59. Entries 
are sorted by TDA paragraph number and then by rank within the position paragraph 
number. 



(7) Monthly Absence Report (see Figure 60). This report provides the 
department with a listing of personnel who have planned absences, either a planned 
CME course or a regular absences (i.e., leave), within an selected month. This report 
is used by the department managers and the clinical director (see scheduling 
information system) to manage personnel assets on a month to month basis. The user 
is required to enter the month and the fiscal year desired prior to output of this report. 
This report is generated by combining the absence databa.se and the CME request 
database and then combining this new database with the personnel database to get the 
rank and name of the person who plans to be absent in the selected month. The report 
file is then sorted by section and last name prior to printing. 



MONTHLY ABSENCE REPORT 

DEPARTMENT OF FAMILY PRACTICE & COMMUNITY MEDICINE 

1 1 MAR 89 



MONTH : JULY 









►FISCAL YEAR : 89 



The following personnel have planned a 
RANK NAME ^ 

CPT JOHN 



CPT 

MSG 

1LT 

SGT 



JANE DOE 
GERY JONES 



@ 






WAYNE SHARPE 
WAYNE ROGERS 



ences during the month of July: 
^ S. 



SECTION 


START DATE END DATE 


TYPE 


AMB 


07/01/89 


07/1 5/89 


CME 


CTM 


06/01/89 


07/02/89 


^ EMER LV 


CTM 


07/09/89 


08/25/89 (^3^ 


LEAVE 


FPC 


07/20/89 


07/22/89 \ 


. PB^W 


POM 


07/30/89 


08/30/89 


ORD TOY 



Figure 60. Monthly Absence Report. 



154 



The helds required to produce this report are: 

• Rank of the person who has an absence planned during the requested month. 

• Last Name. 

• First Name. 

• Section of assignment. 

• Start date of planned absence. 

• End Date of planned absence. 

• Type of Absence. 

The following numbered items correspond with Figure 60. 

1 The fiscal year and month desired are entered by the user prior to output of 
report. If the record in the combined database falls within the requested start date 
or end date, the absence record is included within the report. If the record is 
inclusive of the requested start and end date, e.g., a request in July falls between 
a user specified start date in June and an end date August, the record will be 
included in the report. 

2 Section codes are sorted to keep personnel along organizational lines. The 
secondary sort is on the last name. 

3 Type request code is converted to its full text format. Care must be taken not 
to assign the same type code to both the CME database and the absence database. 

4 The RANK, FIRST NAME, and LAST NAME fields are concatenated to give 
the appearance that the field is one field. 

(8) Fiscal Year Summary of Physician Absences (see Figure 61). This 

summary report provides the Department Chief with the ability to monitor and evaluate 

the number of and frequency of doctor absences within the department. This report 

serves as an indicator of doctor availability over the fiscal year and shows the 

frequency of absences by type of request. This report is generated in the same manner 

as described in the absence report except this report is not restricted to one month and 



155 



extracts only doctor information. The user is only required to enter the fiscal year 
desired. The fields necessary to generate this report are the same as the absence report 
but also include the duration field from both of the databases. 



FISCAL YEAR ABSENCE SUMMARY 
DEPARTMENT OF FAMILY PRACTICE & 
COMMUNITY MEDICINE 
1 1 MAR 89 



FISCAL YEAR : 89 



NAME START DATE END DATE 



LTC JOHN SMUCK 

TYPE : CME REQUEST 
01/01/89 
06/05/89 

Subtotal 

TYPE : ORDINARY LEAVE 
03/05/89 
06/10/89 

Subtotal 






Total. 



LTC JANE SMITH 



TYPE : CME REQUEST 
03/01/89 
04/01/89 
05/05/89 

Subtotal 

►TYPE : PERMISSIVE TDY 
09/25/89 

Subtotal 

►TYPE : ORDINARY LEAVE 
02/01/89 

Subtotal 



01/30/89 

06/10/89 



03/30/89 

06/20/89 



03/30/89 

04/19/89 

05/15/89 



09/30/89 



02/28/89 



Total 



DURATION 




69 days 



29 

18 

12 

57 

_5 

5 



27 




§9 days 



Figure 61. Fiscal Year Summary of Physician Absences. 
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The following numbered items correspond with Figure 61. 

1 Each person identified as having at least one absence during the fiscal year is 
reported in last name order. 

2 Under each person, all absences are sorted by request type in alphabetical order 
with breaks between different types of absences. 

3 Duration is extracted directly from the databases reflecting the End Date minus 
the Start Date in days. 

4 Subtotal of the duration for each type of absence, for each person. 

5 Total duration for all absences for the given person. 

(9) CME Reports (Actual and Estimated) (see Figures 62 and 63). 
These reports allow the Department Chief to monitor the CME expenditures and 
estimate the funds remaining for a given fiscal year. The CME reports are critical in 
keeping track of the limited funds available to send doctors to the training necessary 
to keep them certified in critical medical skUls. 

These two reports are very similar but are used in separate contexts. 
The Actual CME Budget Expenditure Report is used to report the amount actually 
spent during a given fiscal year, excluding all estimated costs figures. This report gives 
the Department Chief an accurate look at the funds remaining for the requested fiscal 
year. The Estimated CME Budget Expendimre report not only gives the Chief a look 
at what funds have actually been spent, but also provides a listing of the approved 
CME funded travel for which travel claims have not yet been settled. This report is 
also used at the beginning of the fiscal year to report the projected expenditures for 
a requested fiscal year. 
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CONTINUING MEDICAL EDUCATION 
ACTUAL FUNDS REPORT 



DEPARTMENT OF FAMILY PRACTICE 
COMMUNITY MEDICINE (TDA) 



11 DEC e9 



NAME 


RANK DATES OF TDY 


LOCATION 


REASON 


travel 


PER 


REG 


REIMB 


TOTAL 


(UNCOMMITTED 




OF TOY 


FOR TDY 


COST 


DIEM 


FEE 


COST 


COST 


\ FUNDS 



FUNDS ALLOCATED 



>>16799.92 



SMITH, JOHN 
JONES, JANE 



CPT 09/09/09-09/20/89 LAS VEGAS, NV ORTHO 

MAJ 10/10/99-11/20/99 RENO, NV AOA 



CUE TRAVEL APPROVED BUT NOT COMPLETED (ESTIMATED COSTS) 
PROJECTED FUNDS REMATNING 



147.00 320,00 395.00 
169.25 437.50 210.00 




Figure 62, Actual CME Budget Expenditure Report 



CONTINUING MEDICAL EDUCATION 
ESTIMATED FUNDS REPORT 



DEPARTMENT OF FAMILY PRACTICE 4 
COMMUNITY MEDICINE (TDA)' 

11 DEC 99 



RANK DATES OF TDY 



LOCATION 
or TDY 



REASON 
FOR TDY 



TRAVEL 

COST 



PER 

DIEM 



REG 

FEE 



REIMB 

COST 



TOTAL ' 
COST 



FUNDS ALLOCATED I 



UNCOMMITTED 
FUNDS 






SMITH, 


JOHN 


CPT 


01/05/99-01/20/99 


LAS 


VEGAS, 


NV 


ORTHO 


147.00 


320.00 


395.00 


0 


962.00 


/-► 15927.92 


JOtJES, 


JANE 


MAJ 


05/10/09-05/20/89 


RENO, NV 




AOA 


169.25 


437.50 


210.00 


50 


866.75 


/ 15061.17 


ANDERS, 


, KEN 


CPT 


07/20/09-00/15/09 


SAN 


DIEGO, 


CA 


EMERG 


100.00 


400.00 


200.00 


50 


750.00 / 


‘ 14311.17 



ALL ESTIMATED AND ACTUAL TRAVEL COSTS REPORTED HERE 




PROJECTED FUNDS REMAINING 14311.17 

Figure 63. Estimated CME Budget Expenditures Report 

The user is required to enter the fiscal year of the report prior to 
creation of either report. The fields required to create these reports are: 

• Last Name of requestor. 

• First Name. 

• Rank of the requestor. 

• Start and End dates of travel. 

• Destination. 
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• Puipose of Request, e.g., ORTHO WORKSHOP. 

• All Costs of travel, including the Travel Cost, Per diem costs, registration fee, 
reimbursable expenses, and total cost fields of the request. 

• Cost Code, whether it is an actual accrued cost or an estimated cost of the 
travel. 

• Allocated CME budget for the fiscal year from the CME allocation database. 

To create this report requires that the CME request database be 
combined with the personnel database to match the name of a person with the PIC in 
the CME request database. The CME allocation database is also used to determine the 
actual allocation for the selected fiscal year. 

The following numbered items correspond with the numbers in 

Figures 62 and 63. 

1 This number is the actual allocation for the current fiscal year selected. 

2 This is an accumulated total of the actual costs incurred for the current fiscal 

year. 

3 This number reflects the allocation for the current fiscal year minus the actual 

expenses already incurred. 

4 This figure is the previous allocation minus the total cost of travel for the 

current record. 

4. Scheduling Information System 

We concluded in Chapter IV that although automating the scheduling system 
would be impractical, improvements could be made in the system by standardizing the 
forms used in data collection and reporting. 

Figure 64 is the UCD depicting the proposed scheduling system. Although 
most of the scheduling process wUl remain the same, the clinical director will now be 
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able to get pre-printed standard forms for recording doctor availability information. 
These forms can be created with commercially available software packages (e.g., 
FORMTOOL) and maintained on diskettes in the administration office. 



Doctor Monthly 
Schedule 



Create 

Doctor 

Schedules 



Doctor 
Availability 
Information 



Department \ 
Appointment \ 
System / 
(COSTARS) / 




Clinical Director 

Scheduling 
Folder 



Record 

Doctor 

Informat’on 



Doctor Information 



Blonk Forms 




Figure 64. Scheduling User Concept Diagram 
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After discussions with the clinical director, it was determined that the most 
valuable forms to standardize are the duty history sheet, the monthly cumulative tally 
sheet, and the clinic schedule template. Other sources of information such as the 3x5 
cards containing staff doctor and resident’s special availability instructions were 
considered to be adequate in their current form. The resulting forms are shown in 
Figures 65 and 66. 

Figure 65 is the Ehity History Record which is a combination of the duty 
history sheet and the monthly cumulative tally sheet. A completed duty history record 
will provide the scheduler with a comprehensive history of each doctor’s on call duty. 

Figure 66 is the clinic schedule template. Since this form is a template, 
the staff doctors permanent schedules are included. The template can be penciled in 
by the scheduler to show residents’ schedules for the month. The resident’s names can 
then be entered into the form using the fill-in-form option of FORMTOOL and a 
complete schedule can be printed for distribution. The clinical director liked the idea 
of the template. The template can be changed easUy and each month a clean template 
can be used without having to first delete the resident’s names firom the previous 
month’s schedule. 



Duly Hislory Record 

OoclofNome Jon Feb Mof Apf Moy Jun Jul Aug Sep Ocl Nov Dec /Weekends /Hdidoys Holidoys 
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M-'nth Yr Schedule Template 



TEAMS 


MONDAY 


TUESDAY 


WEDNESDAiT 


THURSDAY 


FRIDAY 


Gold A 

M 

Lorenzen 

Mork 

Foster 

Birdsong 

Landauer 

Crisp 

Spinelli 

Herman P 

Terrio, H M 




Foster 




Lorenzen 

Foster 




Mork 

Foster 


Lorenzen 

Mork 


Foster 


Mork 


Mork 

Foster 


Red A 

M 

Forred 

Hutnak 

Lee 

Schmidt 

Walcott 

Bradley 

Sorensen 

P 

M 


Forred 


Forred 

Fuller 


Fuller 




Forred 


Fuller 




Forred 


Forred 

Fuller 


Fuller 


Blue A 

M 

Kugler 

Spaulding 

Yeash 

Ard 

Runkle 

Davis 

Goodrich 

Swann 

Terrio,J P 

Weaver M 


Spaulding 

Kugler 


Spaulding 

Yeash 


Kugler 

Yeash 


Spaulding 

Fitzharris 

Yeash 


Spaulding 

Kugler 


Yeash 


Fitzharris 

Kugler 


Spaulding 


Kugler 


Yeash 



Figure 66. Schedule Template 
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5. Patient Satisfaction Information Svstem (see Proprani, Appendix F) 
a. Data Structures 

As can be seen in the UCD in Figure 67, the entire patient satisfaction 
system hinges on completed patient surveys, the results of which are entered into a 
survey database for use in report generation. 




Bfank Survsy 


^ 5urv#/ 


Complete 






Survey 



Doctor 



Potient 



iiiii 






^•porf 



QA Rep, Clerk 



2.0 Print 
Reports 



Rmporis 




CKnlce 



Complmf^d Surv0/ 




Rmpori 

[>ofa 



NSW Survs/ 
Dala 




Clinic ^ 




Dept. ^ 


Reports 




Reports 



7 



lr\puf Data 




QA Rep, Clerk 



Chief 



Figure 67. Patient Satisfaction User Concept Diagram 

TTie approved opinion survey, designed in cooperation with the 
Department Chief and the Quality Assurance (QA) representative, is shown in Figure 
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68. The questions and answers cover those areas of most concern to the Department 
Chief. The survey form determines the data structure of the database itself, with data 
fields corresponding to each question. The following data fields are used in the 
database to record survey data. 

• Month. The month the survey was completed by the patient. 

• Year. Calendar year the survey was taken. 

• Section Code. Same as systems above. 

• Doctor’s Name. The name of the doctor seen by the patient completing the 
survey. 

• Appointment Days. Question lA. 

• Appointment Acceptability. Question IB. 

• Records Ready. Question 2. 

• Waiting Time. Question 3A. 

• Waiting AcceptabUity. Question 3B. 

• Receptionist Courtesy. Question 4. 

• Nursing Courtesy. Question 5. 

• Doctor Courtesy. Question 6 

• Procedures Explanations. Question 7. 

• Time Spent With Doctor. Question 8. 

• Clinic Cleanliness. Question 9. 

• Overall Satisfaction. Question 10. 

• Patient Comments to Enter?. The user entering the survey results into the 
survey database must enter a "Y" in this field to indicate there are comments 
to be added to the database for this survey. An "N" indicates there are no 
comments. The following section on Inputs explains this further. 
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Comments. A memo field which the user can fill from comments made on the 
patient surveys. 



Department of Family Practice 
Patient Opinion Survey 

Your opinion is important to us. Please complete this survey and return it 
to the box located at the reception desk. 

Sincerely, 

Chief, Department of Family Practice 



Month Year Clinic Doctor 



PLEASE CIRCLE THE ANSWER TO THE RIGHT OF EACH QUESTION 



l.A.How many days did it 


1) 


Same 2 ) 


Less 


3) 


Less 


4) Less 


5) 


More 


take to get your 




Day than 7 


than 14 


than 30 


than 30 


appointment ? 


















B.Was this time 


















accept ed^le? 


1) 


Acceptable 




2) 


Not 


Acceptable 






2. Were your records ready 


















at the front desk? 


1) 


YES 




2) 


NO 








3. A. How long did you wait 


1) 


Less 2) 


Less 


3) 


Less 


4) Less 


5) 


More 


to see the doctor? 




than 


than 




than 


than 




than 






15 min 


30 min 




45 min 1 hour 




1 hour 


B.Was the waiting time 


















acceptable? 


1) 


Acceptable 




2) 


Not 


Acceptable 







PLEASE CIRCLE THE NUMBER TO THE RIGHT OF EACH QUESTION WHICH MOST CLOSELY 
MATCHES YOUR OPINION BASED ON THE FOLLOWING SCALE: 



5=Excellent 4=Good 3=OK 2=Needs Improvement 

4. Courtesy of receptionists 

5. Courtesy of nursing staff 

6. Courtesy of doctor 

7. Explanation of procedures (lab work, EKG's, etc). 

8. The amount of time the doctor spent with you 

9. The general cleanliness of the clinic 

10. Overall satisfaction with the care you received.. 

' ■ ■ ■ ■ ■ ■ ■ ■ ' ■ ' — ■ 

COMMENTS : 



l=Unsat isf act 
5 4 3 

5 4 3 

5 4 3 

5 4 3 

5 4 3 

5 4 3 

5 4 3 



ory 
2 1 
2 1 
2 1 
2 1 
2 1 
2 1 
2 1 



THANK YOU ! ! 



Figure 68. Opinion Survey Form 
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b. Data Inputs 

The Patient Opinion menu hierarchy chart is depicted in Figure 69. 
The user can enter new survey data using the input screen shown in Figure 70. This 
input screen contains all of the data base fields arranged in a format similar to the 
actual survey for simplified data entry. The answers to the survey’s numbered 
questions are coded: the user simply enters one number corresponding to the survey 
answer. Since each question has a predetermined number of responses, error checking 
is simply a matter of verifying the input number falls in the allowable range. For 
example, question lA has five possible answers. If the user entered anything other 
than one through five, a bell would sound and a message saying the input was out of 
range would appear at the bottom of the screen. The user is then given the chance to 
enter the correct answer. At the bottom of the input screen the user is asked if there 
are comments to be entered. The user enters a "Y" or "N" in the Patient Comments 
to Enter field. The Patient Comments to Enter field is necessary when printing the 
patient comments report discussed in Outputs below because a memo field in the 
database program cannot be used to determine records to print. Therefore, it is 
necessary to have a second field whose value indicates whether the comment field is 
filled to allow only those records with comments to be printed. 

The use of mark-sense forms would allow automatic entry of the survey 
data into the database. Unfortunately, neither the department nor the hospital has the 
computer hardware to read mark-sense forms and there are no plans to acquire such 
technology. Additionally, we feel the added complexity of mark-sense forms, e.g., 
special marking requirements and additional instructions, would deter some patients 
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from completing the surveys. Also, the requirement to purchase specially designed 
forms may deter the department from obtaining the surveys. 

PATIENT OPINION SYSTEM 




Figure 69. Patient Satisfaction Menu Hierarchy Chart 





YEAP 


■ SECTION CODE m 


— 

DOCTOR ■■■■■■■■■ 




l.A. 


Days to get appointment. 


l.A. 1 


1 






B. 


Accept eJDi lity . 


B. 1 


1 






2. 


Records ready on time. 


2- 1 






3. A. 


Waiting time. 


3. A. 1 


1 






B. 


Acceptability. 


B. 1 


1 






4. 


Courtesy, receptionists. 


4. 








5. 


Courtesy, nurses. 


5. 








6. 


Courtesy, doctors. 


6. 








7. 


Explanation of procedures 


7. 








8. 


Time spent with doctor. 


8. 








9. 


Cleanliness . 


9. 








10. 


General satisf act ion . 


10. 






ARE THEPE COMMENTS TO ADD? 


(Y/N) I 


(Cntrl PgDn to Enter Comments) memo 



Figure 70, Patient Satisfaction Input Screen 
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Once the survey data is entered into the database, the user can print 
one of several reports. After selecting the report desired from the menu, the user is 
prompted to enter information which further identifies the report parameters such as 
year, month, and (if necessary) the clinic’s section code. This information is used to 
gather the data necessary to create the desired output. 
c. Outputs 

(1) Access to Care Reports (see Figure 71). There are two access to 
care reports, one for the department as a whole, and one for each clinic. Both consist 
of two parts and are identical in content and app>earance. However, for clinic reports, 
only the survey data for the selected clinic is used. Part One of the report. 
Acceptability of Appointment Access indicates to the Department Chief the patients’ 
opinions on the acceptability of the length of time it took them to obtain an 
appointment. Part Two, Average Days to Get Appointment, allows the Department 
Chief to examine the trend in the average number of days to get an appointment. 

The following fields are necessary for creating the two part access 

to care reports. 

• Month. 

• Year. 

• Section Code. For clinic report only. 

• Appointment Days. 

• Appointment Acceptability. Required only for Part 1, Acceptability of 
Appointment Access. 
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Acceptability of Appointment Access 




Same day <7 <14 <30 >30 




Acceptable 



Days to Get^pointment 
JULY-r989 

Not Acceptable TotaTKesponses 




JAN 



FEB 



MAR 



APR 

Months 



1089 



MAY 



JUN 



JUL 



Average Days 



Figure 71. Access to Care Report 
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The following numbered items correspond to the numbers shown 
in Figure 71 and explain the data manipulations and calculations required to produce 
the report. 

_1 The total number of responses for each possible answer to survey question lA 
are graphed along the Y-axis based on note 2 below. 

2 For each possible answer to question lA, the number of patients who 
responded to question IB as acceptable and unacceptable are counted and each 
count is graphed as a separate bar. For example, in the figure, for those patients 
that said it took them less than seven days to get an appointment, 15 said this 
was acceptable and one said this was unacceptable. 

3 The total response line shows the total responses for each possible answer to 
question lA, appointment days. 

4 This is the month and year of the survey. This data is input by the user when 
requesting the report and is used by the program to select the appropriate survey 
database records. 

5 In Part Two, the days to get an appointment are graphed on the Y-axis. 

6 The responses to question lA are averaged for each month of the desired year 
and plotted along the X-axis. 

(2) Waiting Time Reports (see Figure 72). As with the access to care 
reports, there are two waiting time reports, one for the department as a whole, and one 
for each clinic. The format of the waiting time report is similar to the access to care 
report for both department and clinic. Part One of the report. Acceptability of Waiting 
Time indicates to the Department Chief the patients’ opinions of the acceptability of 
the length of time it took them to be seen by the doctor. Part Two, Average Waiting 
Time, denotes the trend over the calendar year of the average waiting time to see a 
doctor. 
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Acceptability of Waiting Time 



Number of Responses 
25 




< 15 min < 30 min < 45 min < 1 hour > i hour 



Waiting Time fin minutes) 
JULY 1989 



Acceptable 



Not Acceptable 



* Total Responses 



Average Waiting Time 



Waiting Time (minutes) 




Months 




1969 



Average Waiting Time 



Figure 72. Waiting Time Reports 



171 



The following fields are necessary for creating the two part waiting 

time reports. 

• Month. 

• Year. 

• Section Code. For clinic report only. 

• Waiting Time. 

• Waiting Acceptability. Required only for Part One, Acceptability of Waiting 
Time. 



The following numbered items correspond to the numbers shown 
in Figure 72 and explain the data manipulations and calculations required to produce 
the report. 

1 The total number of responses for each possible answer to survey question 3A 
are graphed along the Y-axis based on note 2 below. 

2 For each possible answer to question 3A, the number of patients who 
responded to question 3B as acceptable and unacceptable are counted and each 
count is graphed as a separate bar. For example, in the figure, for those patients 
that said it took them less than 30 minutes to see a doctor, 17 said this was 
acceptable and three said this was unacceptable. 

3 The total response line shows the total responses for each possible answer to 
question 3A, waiting time. 

4 This is the month and year of the survey. This data is input by the user when 
requesting the report and is used by the program to select the appropriate survey 
database records. 

5 In Part Two, the waiting time is graphed on the Y-axis. 

6 The responses to question 3A are averaged for each month of the desired year 
and plotted along the X-axis. 

(3) Satisfaction Indicators (see Figure 73). Questions four through ten 
of the survey are statements for which the patient is asked to indicate his level or 
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degree of satisfaction ranging from five for excellent to one for unsatisfactory. The 
Satisfaction Indicator report shows the results of the survey in these seven areas, with 
the total number of responses for each level of satisfaction (one through five) graphed 
for each of the seven areas. 
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Figure 73. Satisfaction Indicators 

The following fields are necessary for creating this report: 



• Month. 



Year. 

Section Code. For clinic report only. 
Receptionist Courtesy. 
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• Nursing Courtesy. 

• Doctor Courtesy. 

• Procedure Explanations. 

• Time Sp>ent With Doctor. 

• Clinic Cleanliness. 

• Overall Satisfaction. 

The following numbered items correspond to the numbers in Figure 
73 and explain the data manipulations required to produce the graph. 

1 The Month and Year for the report. 

2 The total number of responses in each level of satisfaction are graphed along 
the Y-axis. 

3 For each satisfaction indicator (e.g., doctor courtesy, overall satisfaction) the 
number of responses in each level of satisfaction (note 4 in the figure) are 
counted and the total for each level is graphed as a separate bar for all of the 
indicators along the X-axis. 

(4) Average Satisfaction Levels (see Figure 74). This two part report 
shows the average level of satisfaction for each satisfaction indicator for the calendar 
year. It is presented in two reports to simplify viewing. The Department Chief prefers 
line graphs to enhance trend identification so the seven indicators are divided into two 
groups. Part One shows the indicators which are primarily personnel oriented (e.g., 
courtesy) plus overall satisfaction. Part Two shows the remaining indicator’s averages. 

The following fields are necessary to create the two part report: 

• Month. 

• Year. 

• Section Code. For clinic report only. 
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• Receptionist Courtesy. For Part One only. 

• Nursing Courtesy. For Part One only. 

• Doctor Courtesy. For Part One only. 

• Overall Satisfaction. For Part One only. 

• Procedure Explanations. For Part Two only. 

• Time Spent With Doctor. For Part Two only. 

• Clinic Cleanliness. For Part Two only. 

The following numbered items correspond to the numbers in Figure 
74 and explain the data manipulations required to produce this report. 

1 This is the requested year of the survey data for the report. 

2 The average of all of the values (ranging from one to five) for each indicator 
is calculated for each month of the specified year. The satisfaction indicators are 
plotted along the X-axis using different line styles for each indicators average 
values. 

3 The average response for each indicator is correlated to it’s equivalent narrative 
description, i.e., 1 = unsatisfactory, and these are shown along the Y-axis. 

(5) Doctor Satisfaction Report (see Figure 75). This report is a table 
showing the average responses for a given month for four of the satisfaction indicators 
which most directly relate to the patient’s interactions with the doctors. This report 
is produced for all of the doctors in the department and allows the Department Chief 
to track individual doctor’s survey results. 
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The following fields are necessary for creating this report: 



• Year. 

• Month. 

• Doctor Name. 

• Doctor Courtesy. 

• Procedure Explanations. 

• Time Spent With Doctor. 

• Overall Satisfaction. 

The numbered items below correspond to Figure 75 and explain 
how the data for the report is obtained. 

1 This is the month and year for the report. 

2 Each doctor’s name is printed in the first column in alphabetical order. 

3 For each doctor, the average response for the four indicators is calculated and 
placed in the corresponding column adjacent to the doctors name. 

4 The value of all four indicators is averaged to produce an overall doctor 
satisfaction average. 

5 An additional indicator of a physician’s consistency could be computer here, 
e.g., standard deviation or some similar measure of dispersion. 
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(6) Patient Comments (see Figure 76). This report is a print out of 
all of the patient comments entered into the survey database for the desired month and 
year. It allows the Department Chief to review any constructive criticisms or 
noteworthy suggestions made by the patients and pinpoint other trouble areas (or 
outstanding areas) which cannot be identified from the quantitative portion of the 



survey. 



The fields necessary to produce this report are listed below: 



• Month. 



• Year. 



• Patient Comments to Enter? 



• Comments. 



The numbered items below, corresponding to Figure 76, explain 



the comment report. 



1 The month and year of the report is listed at the top. 

2 The records in the database which have the Comments field filled (indicated 
by a "Y" in the Patient Comments to Enter field) are printed in record number 
order for the month and year. 



PATIENT COMMENTS 
July 1989 



© 



I THINK THE LAB AND PHARMACY TAKE TOO LONG, I WAITED FOR MORE 
TO GET MY PRESCRIPTION FILLED. 



THAN AN HOUR 



THE FAMILY PRACTICE CLINIC IS GREAT HERE. I WOULD LIKE TO BE ABLE TO SEE 
MY ASSIGNED DOCTOR MORE OFTEN, DR. YEASH, BUT WHOEVER SEES ME IS ALWAYS 
VERY COURTEOUS AND HELPFUL. 



I NEVER GET TO SEE THE DOCTOR WHICH MY FAMILY IS ASSIGNED TO, WHY BOTHER 
GOING THROUGH THE HASSLE OF SIGNING UP FOR A SPECIFIC DOCTOR? 



ITS TOO COLD IN THE EXAMINING ROOMS. 



Figure 76. Patient Comments Report 
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6. Productivity Information System (see Program, Appendix G) 
a. Data Structures 

The productivity system UCD is shown in Figure 77. The functions 
of the productivity system depend on visit information obtained from the Patient 
Administration Division for each section of the department. The method of obtaining 
the visit information is described in the next section, Inputs. 




Report 

Selections 




Report 

Selections 




Figure 77. Productivity System User Concept Diagram 
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The visit information is entered into the visit database which consists 



of the following fields; 

• Fiscal Year. The fiscal year is used so the number of visits in each section can 
be directly compared to the section’s expenditures for each month. 
Expenditure data is maintained in the budget database by fiscal year. 

• Month. 

• Section Code. 

• Number of Visits. The number of patient visits for each section within the 
department as reported by the Patient Administration Division. 

b. Data Inputs 

The productivity system menu hierarchy chart is shown in Figure 78. 
Visit data for the entire hospital is collected monthly by the Patient Administration 
Division (PAD) for RMD. PAD enters each section’s visit information into a 

spreadsheet program which they use to create the MED 302 report, discussed in 
Chapters III and IV. For the department productivity system, the visit information can 
be extracted from the PAD MED 302 file for entry into the visit database. Table VI 
shows the locations of visit data in the MED 302 spreadsheet file corresponding to 
each section in the DFPCM. As can be seen in the Table VI, some calculations on 
the data in the file are necessary to accurately correlate the visit data to the DFPCM 
sections. For example, the CTMC section visit count is a combination of multiple 
lines and columns from the MED 302 file. The disparity occurs because PAD divides 
section visits into subdivisions for their hospital reporting requirements. For the 
Department Chief’s purposes, only the total visit information for each section is 
necessary. 
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Table VI. MED 302 DATA EXTRACTION LOCATIONS 



SECTION CODE LOCATION IN MED 302 (LINE #’s & CPUs) 
FPC SUM (134 A & B TO 140 A & B) 

CFP SUM (134C TO 140C) 

EMS SUM (147 A & B) 

FSO SUM (148 A & B) 

GOC SUM (141 A & B) 

POM 141D 

CTM SUM (141C, 171C, 174C, 141F) 

FHL SUM (141 E, 171 E, 174E) 



PRODUCTIVITY SYSTEM 




Figure 78. Productivity Menu Hierarchy Chart 



The visit information in the MED 302 file can be extracted for entry 



into the visit database in one of two general ways, either automatically or manually. 



181 



To extract the visit data automatically, an extraction program can be 
written to take data from the MED 302 spreadsheet file and load it on a floppy disk. 
Another program is necessary to transfer the data from the disk into the department 
productivity system’s visit database in the correa format. 

Manual extraction would require PAD to print the department’s sections 
and visit data, monthly, to a paper report. The user of the department productivity 
system would select the "Add Visit Data" option from the "Update Visit Data" menu 
and enter the visit data contained in the printed report provided by PAD. The input 
screen for adding, changing, or removing visit data is shown in Figure 79. 



Fiscal Yaar 


Month 


Sactlon Code 


♦ of Visits 


■ 


■ 


■1 


■■ 





Section 


Codes 




Family Practice Clinic 


FPC 


Consolidated Troop Clinic 


CTM 


General Outpatient Clinic 


GOC 


Fort Hunter Liggett 


FHL 


CTMC Feunily Practice 


CFP 


Ambulance Section 


AMB 


Emergency Medical Service 
Presidio of Monterey 


EMS 

POM 


Flight Surgeon Office 


FSO 



Figure 79. Visit Data Input Screen 

Either of the above input methods is technically feasible. However, 
there are tradeoffs in choosing one method over the other. The automated method 
eliminates the need for manual entry of each section’s visit data every month. On the 
other hand, the amount of data entry is relatively small. There are eight sections with 
visit data requiring approximately 11 keystrokes for each section (see Figure 79). 
Thus, in any given month, it would require approximately 90 keystrokes to enter the 
new visit information into the database. The main drawback to automating the 
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information extraction lies in the MED 302 file itself. PAD created the spreadsheet 
file for their own use in creating the hospital’s MED 302 report. The DFPCM has no 
control over PAD’s use of the spreadsheet fUe. Therefore, any changes PAD might 
make to the file would cause any extraction program referencing specific lines and 
columns to fail. Other changes in the method of visit data collection or reporting 
would likely require changes in the extraction programs. Both extraction methods 
require cooperation and coordination between the DFPCM and the PAD, with the 
automated method requiring considerably greater effort. 

The method of extraction aside, once the data is contained in the 
database, the user can view the data by selecting one of the outputs described in the 
following section. 

c. Outputs 

(1) Review Visit Data. The review is an option under the "Update 
Visit Data" menu and allows the user to view the entire visit database. All of the 
database fields are displayed in the standard review format described in Section C.2.b., 
Review Screens. 

(2) Department Monthly Visit Report (see Figure 80). The monthly 
visit report is a bar graph showing each sections’ total visits for the desired fiscal year 
and month. This report provides the Department Chief with a quick indication of the 
level of work done by each of the eight sections reporting visit information. All of 
the visit database fields are necessary to create the monthly visit report. 
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The following numbered items correspond to the numbers in Figure 
80 and explain the monthly visit report: 

\ The month and year for the report. 

2 The total number of visits (in thousands) for each clinic is plotted on the Y- 
axis. 

3 The eight department sections are plotted along the X-axis. 



DEPARTMENT MONTHLY VISITS 

IMS 



® 

Number of Visits (thousands) 




CTM FPC EMS GOC CFP FHL FSO 
( 3 ) Department of Family Practice Sections 



POM 



Figure 80. Department Monthly Visit Report 

(3) Visit Trend Report (see Figure 81). The visit trend report is a 
multiple graph report showing fiscal year trends in patient visits for each section. To 
simplify viewing, only two sections are shown on each graph resulting in four graphs 
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for the entire report. All of the visit database fields are required for the visit trend 
report. 

The following numbered items correspond to the numbers in Figure 
81 and explain the visit trend report. 

1_ The fiscal year of the report. 

2 The number of visits for each clinic is plotted in the appropriate graph on the 
Y-axis. 

3 Each month of the reported fiscal year is graphed along the X-axis. There are 
two sections plotted on each graph, each with a different trend line style. 

(4) ExpenditureA^isit Comparison Report (see Figure 82). The 
expenditure/visit comparison report shows the dollar amount spent per patient visit. To 
obtain the data necessary to produce this report, the information in the visit database 
must be combined with information from two of the databases maintained by the 
budget system: the APC monthly expenditure database; and the APC database. 
Because of the relationship between the APC and the Section Code, the visit database 
must first be combined with the APC database to relate the visit database section code 
with the APCs used in the budget system. The resulting combination must further be 
combined with the APC monthly expenditure database. This combination is necessary 
to relate the number of visits for a particular section code to that section’s expenditures 
for the same month and fiscal year desired for the report. The three databases and 
their field relationships are shown in Figure 83. 
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Expenditure/Visit Comparison 

July 1989 



$ Expended Per Visit 





Figure 82. Expenditure/Visit Comparison 

The combined data fields necessary to create the report are listed 



below: 

• Fiscal Year. 

• Month. 

• Section Code. 

• APC. 

• Expenditure. 

• Number of Visits. 
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The following numbered items conesp>ond to the numbers in Figure 
82 explaining the comparison report. 

1_ The month and fiscal year of the report. 

2 The dollar expenditure f>er patient visit is plotted along the Y-axis. For each 
section, divide the monthly expenditure by the monthly number of visits to arrive 
at the expenditure per visit amount. 

3 Each section is plotted along the X-axis with a vertical bar showing the dollar 
expenditure per visit. 



VISIT DATABASE 




APC DATABASE 



MONTHLY EXPENDITURE DATABASE 



Figure 83. Productivity and Budget Database Relationships 

(5) Department Expenditure and Visit Trend Report (see Figure 84). 
The expenditure and visit trend report aUows the Department Chief to rapidly assess 
the general direction department spiending is taking in comparison to the department’s 
workload. The process for obtaining the information for the report is similar to that 
used in the ExpenditureA^isit Comparison report discussed previously. The same 
combined database fields are used in both reports, however, the calculations for each 
report are different. 
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The following numbered items correspond to the numbers in Figure 
84 and explain the data calculations required to produce the expenditure and visit trend 
report. 

1 The fiscal year of the report. 

2 The dollar amount of department expenditures for each month of the fiscal 
year. Sum the eight section’s expenditure data for each month to obtain the total 
monthly department expenditures. 

3 The number of department visits for each month of the fiscal year. Sum the 
eight sections’ visit data for each month to obtain the total monthly department 
visits. 

4 The dollar amount of expenditures and file number of visits are both plotted 
on the Y-axis. The numbers along the Y-axis represent both thousands of dollars 
and thousands of visits. 



189 



DEPARTMENT EXPENDITURE AND VISIT TRENDS 

1969 



4 ’ © 

f or Visits in Thousands 




@ ( 3 ) 

I Expenditures — • — § Visits 



Figure 84. Department Expenditure and Visit Trend Report 
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VI. CONCLUSIONS AND RECOMMENDATIONS 



A. PROJECT SYNOPSIS 

We began our information systems development project for Silas B. Hays by 
studying the current literature on information systems development and hospital 
information systems. The findings of this literamre research were presented in Chapter 
n. In summary, there were a multitude of systems development methodologies from 
which to choose. We determined that a combination of two commonly used 
methodologies, a traditional systems development life cycle and a prototyping 
methodology, would best fit our needs. The life cycle methodology provided us with 
the stmctured techniques to develop the proposed information system, while prototyping 
allowed us to quickly develop the user interfaces necessary to rapidly identify user 
requirements. Through research, we determined that the critical nature of the health 
care environment influences the information systems used by hospitals. There exists 
a dichotomy between the goals and objectives of hospital administrators and health care 
providers. This dichotomy influences the way in which information systems are used 
to meet these differing objectives. Additionally, the resource constraints within the 
hospital create pressures when considering the use of information systems by both 
administrators and health care providers. This was particularly true in the case of the 
DFPCM, whose Chief is both a health care provider, and by necessity, an administrator. 

We conducted interviews with senior hospital managers to obtain a clear problem 
definition and to focus our research. The feedback from these discussions directed us 



191 



to the Department of Family Practice and Community Medicine (DFPCM). This large, 
multi-service department greatly affects overall hospital operations. Chapter in 
provided a detailed look at the DFPCM: its structure and its current information 
systems. The Chief of the DFPCM commands more than 150 people and manages an 
annual budget of nearly half a million doUars. In initial discussions with the Chief, 
he identified and prioritized his most critical management concerns: budget, equipment, 
personnel, scheduling, patient satisfaction, and productivity. The information systems 
relating to these six management areas became the subject of our research. 

Discussions with the Department Chief and his senior department personnel 
helped us identify their requirements for information in each of the six areas. In 
analyzing their needs, and comparing the needs with the current information systems, 
we were able to propose improvements to the systems in Chapter IV. Those 
improvements included: the use of databases; simpler data collection; automated data 
manipulations (in some cases); concise, summary reports; graphical reports; trend 
analysis capabilities; and improved automated user interfaces (where applicable). 

The improvements proposed in Chapter IV were prototyp>ed in Chapter V to 
produce a detailed requirements analysis for the six information systems in the DFPCM. 
The databases, user interface screens, and outputs of the systems were designed to help 
us pinpoint the user’s requirements. The Department Chief and other department 
managers provided feedback, allowing us to tailor the prototyped models to their 
specifications. Time constraints allowed only one iteration of the prototyping process. 
Further iterations would further enhance the requirements analysis presented in Chapter 
V. 
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The general conclusions resulting from our research are presented in the following 
section. The recommendations for follow on thesis study are discussed in the last 
section of this chapter. 

B. CONCLUSIONS 

The requirements analysis presented in this thesis is the first step in the 
development life cycle for the DFPCM information system. With the existing 
information system defined and the requirements identified and analyzed, the system 
can be fully designed, constructed, and implemented to meet the needs of the targeted 
department users. 

The process of requirements analysis is a complex task which if done poorly will 
likely result in a substandard system development. The complexity of this task leads 
to many difficulties which the analysts must face during the development process. 

Identifying the system’s target audience and obtaining a clear problem definition 
are essential first steps in the process. Without a clear understanding of the intended 
users and their related problems, the analyst’s energies and resources are wasted on 
unimportant or non-existent requirements. Starting on the right track early in the 
process requires the involvement of senior management to obtain the input from those 
personnel who are in a position to identify problem areas. Once involved in the thesis 
study, the senior managers at SUas B. Hays were quick to identify the DFPCM as 
potential benefitors of an improved information system. Frequent and early interactions 
with the users were critical in identifying the detailed requirements of each of the 
subsystems presented. 
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Selecting the "best" development methodology is the next hurdle in the 
development process. Given the large number of methodologies in existence, it is 
doubtful there is one "best" method. Rather, the analyst must choose the methodology 
most suited to the task at hand, with which he has the most exj>erience, or simply, one 
which he feels most comfortable using. Decisions such as whether to use data flow 
diagrams or user concept diagrams depends on a number of factors, the bottom line 
being whether or not the analyst can use the method effectively to build a high quality 
system acceptable to the intended users. 

The use of prototyping in the early stages of system’s development was shown 
to be beneficial in identifying the inputs, interfaces, and output requirements desired 
by the intended users. Using separate software packages to design the various 
prototypes was time consuming and did not allow direct integration of the input and 
output prototype programs. The use of a dedicated, integrated prototype tool which 
does all of these processes could have greatly enhanced our productivity in prototype 
development. 

The project management of the system development is critical for an efficient and 
effective process. The division of labor, coordination of effort, and teamwork were 
important issues throughout the project. When these factors are missing or inadequate 
in project development, schedules slip and resources are wasted. 

An important influence in the development project at SUas B. Hays is the 
complexity of the computer systems in place at the hospital. The lack of integration 
of these systems frustrates the development of an information system and ultimately 
causes more work for the users in duplicating the data collection and reporting efforts. 
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The integrated Composite Health Care System planned for implementation in the early 
1990s does not answer the needs of the department managers today. The new Director 
of Information Management at Silas B. Hays has begun planning for solving the 
integration problems using networking technology. 

A valuable lesson learned during the writing of this thesis was that the use of 
automation is not always appropriate in every part of an information system. In some 
cases, automation would actually create more work in relation to any benefits gained. 
With the intense workload of the department’s personnel, every effort must be made 
to reduce the amount of work required while providing the best possible information 
to the department chief. 

C. RECOMMENDATIONS AND FOLLOW-ON THESIS WORK 

The requirements analysis presented in this thesis should be used to further design 
and implement a complete information system for the DFPCM. The hospital’s 
Information Management Division can use the prototype program listings, and input and 
output examples to develop a working system using the software packages currently 
available in the hospital, or they can use the requirements to justify purchasing or 
developing other software as required to implement the systems. Possible follow on 
thesis work in this area includes designing, constructing, and/or implementing an 
information system from a previously developed requirements analysis. Evaluating and 
selecting software and hardware alternatives, including thorough economic analyses, 
provide additional possibilities for future research. 

The information which could be provided to hospital managers by a completed 
system may be useful to other hospital departments. Follow on thesis work could 
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involve expanding the initial requirements analysis of this thesis to other departments 
or the hospital as a whole. 

Additional foUow-on thesis work include: research into the design of an 
optimization model for the doctor scheduling process and further research into the 
doctor productivity issues discussed in Chapter IV. 

At a minimum, the analysis contained in this thesis can be used by senior 
hospital managers to identify the shortcomings of the existing information systems in 
providing department managers with the high quality information they require to 
successfully manage the many resources needed to accomplish their missions. 
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APPENDIX A. DATA DICTIONARY 



BUDGET DATABASE FILES 



APC FILE 


FIELD 

NAME 


FIELD 

TYPE 


FIELD 

LENGTH/ 

DECIMALS 


DESCRIPTION 
OF FIELD 


APC 


CHARACTER 


4 


0 


ACCOUNT PROCESSING CODE : FORMAT A999 


SECTION 


CHARACTER 


20 


0 


NAME OF SECTION ASSIGNED TO APC CODE 


SECTCODE 


CHARACTER 


3 


0 


SECTION CODE 


POC 


CHARACTER 


15 


0 


POINT OF CONTACT 


TELEPHONE 


NUMERIC 


9 


0 


TELEPHONE NUMBER : FORMAT (999) 999-9999 


STATUS 


CHARACTER 


1 


0 


STATUS CODE [ A: ACTIVE, I : INACTIVE ] 



QTRALLOC FILE 


FIELD 


FIELD 


FIELD 


DESCRIPTION 


NAME 


TYPE 


LENGTH/ 

DECIMALS 


OF FIELD 


APC 


CHARACTER 


4 


0 


ACCOUNT PROCESSING CODE 


FY 


NUMERIC 


2 


0 


FISCAL YEAR OF ALLOCATION 


QUARTER 


NUMERIC 


1 


0 


QUARTER WITHIN THE FISCAL YEAR 


ALLOCATION 


MONEY 


11 


2 


BUDGET ALLOCATION FOR THE QUARTER 



MOEXP FILE 


FIELD 


FIELD 


FIELD 


DESCRIPTION 


NAME 


TYPE 


LENGTH/ 

DECIMALS 


OF FIELD 


APC 


CHARACTER 


4 


0 


ACCOUNT PROCESSING CODE 


MONTH 


NUMERIC 


2 


0 


MONTH THE EXPENSE OCCURRED 


FY 


NUMERIC 


2 


0 


FISCAL YEAR OF EXPENDITURE 


QUARTER 


NUMERIC 


1 


0 


COMPUTED, BASED ON MONTH 


EXPENSES 


MONEY 


11 


2 


DOLLARS EXPENDED FOR MONTH 
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EQUIPMENT DATABASE FILES 



EQUIP FILE 


FIELD 

NAME 


FIELD 

TYPE 


FIELD 

LENGTH/ 

DECIMALS 


DESCRIPTION 
OF FIELD 


EQCODE 


NUMERIC 


7 


2 


EQUIPMENT REQUEST NUMBER (GENERATED) 


SECTCODE 


CHARACTER 


3 


0 


SECTION CODE 


REQDATE 


DATE 


8 


0 


DATE OF ORIGINAL REQUEST 


DESCRIPT 


CHARACTER 


20 


0 


DESCRIPTIVE NAME OF EQUIPMENT NEEDED 


REQTYPE 


CHARACTER 


4 


0 


TYPE OF EQUIPMENT REQUEST, i.e. CEEP 


PRIORITY 


NUMERIC 


2 


0 


PRIORITY OF REQUEST WITHIN TYPE OF EQUIP 


URGCODE 


NUMERIC 


1 


0 


URGENCY OF REQUEST ( 0 TO 4 ) 


QTY 


NUMERIC 


3 


0 


QUANTITY OF EQUIPMENT NEEDED 


UNITPRICE 


MONEY 


9 


2 


PRICE PER UNIT OF EQUIPMENT REQUESTED 


EXTPRICE 


MONEY 


10 


2 


EXTENDED PRICE OF EQUIPMENT 


STATUS 


CHARACTER 


2 


0 


STATUS OF REQUEST IN CODED FORM 


COMMENTS 


CHARACTER 


20 


0 


COMMENTS ON REQUEST 



EQHIST FILE 


FIELD 


FIELD 


FIELD 


DESCRIPTION 


NAME 


TYPE 


LENGTH/ 

DECIMALS 


OF FIELD 


SECTCODE 


CHARACTER 


3 


0 


SECTION CODE 


DESCRIPT 


CHARACTER 


20 


0 


DESCRIPTIVE NAME OF EQUIPMENT NEEDED 


REQTYPE 


CHARACTER 


4 


0 


TYPE OF EQUIPMENT REQUEST, i.e. CEEP 


QTY 


NUMERIC 


3 


0 


QUANTITY OF EQUIPMENT NEEDED 


EXTPRICE 


MONEY 


10 


2 


EXTENDED PRICE OF EQUIPMENT 


REQDATE 


DATE 


8 


0 


DATE OF ORIGINAL REQUEST 


XFERDATE 


DATE 


8 


0 


DATE TRANSFERRED TO HISTORICAL FILE 


MO_TO_COMP 


NUMERIC 


3 


0 


MONTHS IT TOOK TO COMPLETE REQUEST 


COMMENTS 


CHARACTER 


20 


0 


COMMENTS ON REQUEST 



198 



PERSONNEL DATABASE FILES 



PERSONNEL FILE 


FIELD 

NAME 


FIELD 

TYPE 


FIELD 

LENGTH/ 

DECIMALS 


DESCRIPTION 
OF FIELD 


IDCODE 


CHARACTER 


5 


0 


PERSONNEL IDENTIFICATION CODE 


LNAME 


CHARACTER 


20 


0 


LAST NAME 


FNAME 


CHARACTER 


15 


0 


FIRST NAME, MIDDLE INITIAL 


RANK 


CHARACTER 


3 


0 


RANK OF PERSON 


BRANCH 


CHARACTER 


2 


0 


BRANCH OF PERSON 


MOS 


CHARACTER 


5 


0 


MILITARY OCCUPATIONAL SPECIALTY CODE 


STATUS 


NUMERIC 


1 


0 


RESIDENCY CODE (IF IN RESIDENCY PROGRAM) 


ALOSS 


DATE 


8 


0 


ANTICIPATED DATE OF LOSS 


ARRDATE 


DATE 


8 


0 


ARRIVAL DATE IN DEPARTMENT 


TDA_PARA 


NUMERIC 


3 


0 


TDA PARAGRAPH NUMBER ASSIGNED TO PERSON 


TDA_LINE 


CHARACTER 


3 


0 


TDA LINE NUMBER ASSIGNED TO PERSON 


TDA_POSN 


NUMERIC 


2 


0 


TDA POSITION NUMBER ASSIGNED TO PERSON 



PERSONAL FILE 


FIELD 


FIELD 


FIELD 


DESCRIPTION 


NAME 


TYPE 


LENGTH/ 

DECIMALS 


OF FIELD 


IDCODE 


CHARACTER 


5 


0 


PERSONNEL IDENTIFICATION CODE 


ADDRESS 


CHARACTER 


20 


0 


PERSON'S ADDRESS (HOME) 


CITY 


CHARACTER 


20 


0 


CITY (HOME) 


STATE 


CHARACTER 


2 


0 


STATE (HOME) 


ZIPCODE 


NUMERIC 


9 


0 


ZIPCODE + 4 (HOME) 


WIFE 


CHARACTER 


10 


0 


WIFE'S NAME 


CHILDREN 


CHARACTER 


25 


0 


CHILDREN'S FIRST NAMES AND AGES 


TELEPHONE 


NUMERIC 


9 


0 


TELEPHONE NUMBER WITH AREA CODE (HOME) 


DOR 


DATE 


8 


0 


DATE OF RANK 


COMMENTS 


CHARACTER 


30 


0 


COMMENTS (PERSONAL) 
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TDA FILE 


FIELD 


FIELD 


FIELD 


DESCRIPTION 


NAME 


TYPE 


LENGTH/ 

DECIMALS 


OF FIELD 


TDA_PARA 


NUMERIC 


3 


0 


TDA PARAGRAPH NUMBER 


TDA_LINE 


CHARACTER 


3 


0 


TDA LINE NUMBER 


TDA_POSN 


NUMERIC 


2 


0 


TDA POSITION NUMBER 


JOB_TITLE 


CHARACTER 


20 


0 


OFFICIAL JOB TITLE AS STATED ON TDA 


APC 


CHARACTER 


4 


0 


ACCOUNT PROCESSING CODE 


AUTH_BR 


CHARACTER 


2 


0 


AUTHORIZED BRANCH OF SERVICE 


AUTH_GR 


CHARACTER 


2 


0 


AUTHORIZED GRADE (RANK) 


AUTH_MOS 


CHARACTER 


6 


0 


MILITARY OCCUPATIONAL SPECIALTY CODE 


AUTH 


CHARACTER 


1 


0 


AUTHORIZED SLOT CODE (FROM TDA) 



ABSENCE FILE 


FIELD 

NAME 


FIELD 

TYPE 


FIELD 

LENGTH/ 

DECIMALS 


DESCRIPTION 
OF FIELD 


IDCODE 


CHARACTER 


5 


0 


PERSONNEL IDENTIFICATION CODE 


FY 


NUMERIC 


2 


0 


FISCAL YEAR OF ABSENCE REQUEST 


TYPE 


CHARACTER 


1 


0 


TYPE OF ABSENCE (CODED) 


START 


DATE 


8 


0 


START DATE OF ABSENCE 


END 


DATE 


8 


0 


END DATE OF ABSENCE 


DURATION 


NUMERIC 


3 


0 


CALCULATE (START DATE - END DATE) 


COMMENTS 


CHARACTER 


30 


0 


COMMENTS ABOUT ABSENCE REQUEST 



CME ALLOC FILE 


FIELD 


FIELD 


FIELD 


DESCRIPTION 


NAME 


TYPE 


LENGTH/ 

DECIMALS 


OF FIELD 


FY 


NUMERIC 


2 


0 


FISCAL YEAR OF CME FUNDS ALLOCATION 


ALLOCATION 


MONEY 


11 


2 


CME FUNDS ALLOCATION FOR THE FY 
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CMEPEQ FILE 


FIELD 


FIELD 


FIELD 


DESCRIPTION 


NAME 


TYPE 


LENGTH/ 

DECIMALS 


OF FIELD 


IDCODE 


CHARACTER 


5 


0 


PERSONNEL IDENTIFICATION CODE 


FY 


NUMERIC 


2 


0 


FISCAL YEAR OF REQUEST 


TYPE 


CHARACTER 


1 


0 


TYPE OF CME REQUEST (ONE DIGIT CODE) 


START 


DATE 


8 


0 


START DATE OF CME TRAVEL 


END 


DATE 


8 


0 


ENDING DATE OF CME REQUEST 


DURATION 


NUMERIC 


3 


0 


CALCULATED (END DATE - START DATE) 


LOCATION 


CHARACTER 


20 


0 


LOCATION OF REQUESTED CONFERENCE 


PURPOSE 


CHARACTER 


20 


0 


PURPOSE OF CME TRAVEL 


TVIMODE 


CHARACTER 


1 


0 


MODE OF TRAVEL (CODED) 


TRAVELCOST 


MONEY 


7 


2 


COST OF TRAVEL 


PERDIEM 


MONEY 


7 


2 


PER DIEM COSTS OF TRAVEL 


REGFEE 


MONEY 


7 


2 


REGISTRATION FEES 


REIMS 


MONEY 


6 


2 


REIMBURSABLE EXPENSES 


TOTALCOST 


MONEY 


8 


2 


TRAVELCOST+PERDIEM+REGFEE+REIMB 


C_CODE 


CHARACTER 


1 


0 


COST CODE (A=ACTUAL OR E=ESTIMATED) 



ABSENCE FIDE 


FIELD 


FIELD 


FIELD 


DESCRIPTION 


NAME 


TYPE 


LENGTH/ 

DECIMALS 


OF FIELD 


IDCODE 


CHARACTER 


5 


0 


PERSONNEL IDENTIFICATION CODE 


FY 


NUMERIC 


2 


0 


FISCAL YEAR OF ABSENCE REQUEST 


TYPE 


CHARACTER 


1 


0 


TYPE OF ABSENCE (CODED) 


START 


DATE 


8 


0 


START DATE OF ABSENCE 


END 


DATE 


8 


0 


END DATE OF ABSENCE 


DURATION 


NUMERIC 


3 


0 


CALCULATE (START DATE - END DATE) 


COMMENTS 


CHARACTER 


30 


0 


COMMENTS ABOUT ABSENCE REQUEST 
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SATISFACTION DATABASE FILE 



SURVEY FILE 


FIELD 

NAME 


FIELD 

TYPE 


FIELD 

LENGTH/ 

DECIMALS 


DESCRIPTION 
OF FIELD 


MONTH 


NUMERIC 


2 


0 


MONTH SURVEY TAKEN 


YEAR 


NUMERIC 


2 


0 


YEAR SURVEY TAKEN 


SECTCODE 


CHARACTER 


3 


0 


SECTION CODE (FROM SURVEY) 


DOCTORNAME 


CHARACTER 


20 


0 


DOCTOR'S LAST NAME, FIRST NAME, MI 


APPTDAYS 


NUMERIC 


1 


0 


NUMBER OF DAYS TO GET APPOINTMENT 


ACCAPPT 


NUMERIC 


1 


0 


ACCEPTABILITY OF DAYS TO GET APPOINTMENT 


RECORDS 


NUMERIC 


1 


0 


WERE MEDICAL RECORDS READY? 


WAITTIME 


NUMERIC 


1 


0 


WAITING TIME SCORE 


ACCWAIT 


NUMERIC 


1 


0 


ACCEPTABILITY OF WAITING TIME SCORE 


RECEPT 


NUMERIC 


1 


0 


COURTESY OF RECEPTIONIST SCORE 


NURSE 


NUMERIC 


1 


0 


COURTESY OF NURSES SCORE 


DOCTORS 


NUMERIC 


1 


0 


COURTESY OF DOCTORS SCORE 


EXPLAIN 


NUMERIC 


1 


0 


EXPLANATIONS OF PROCEDURES SCORE 


TIMESPENT 


NUMERIC 


1 


0 


ADEQUACY OF TIME SPENT WITH DOCTOR SCORE 


CLEAN 


NUMERIC 


1 


0 


CLEANLINESS OF CLINIC SCORE 


SATIS 


NUMERIC 


1 


0 


GENERAL SATISFACTION^ SCORE 


PATCOMMENT 


CHARACTER 


1 


0 


ARE THERE PATIENT COMMENTS TO ENTER? 


COMMENTS 


MEMO 


10 


0 


COMMENTS MEMO FIELD 



SCORE : NUMBER MARKED ON PATIENT'S SURVEY QUESTIONNAIRE 
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PRODUCTIVITY DATABASE FILE 









VISIT FILE 


FIELD 


FIELD 


FIELD 


DESCRIPTION 


NAME 


TYPE 


LENGTH/ 

DECIMALS 


OF FIELD 


FY 


NUMERIC 


2 


0 


FISCAL YEAR OF VISIT INFORMATION 


MO 


NUMERIC 


2 


0 


MONTH OF VISIT INFORMATION 


SECTCODE 


CHARACTER 


3 


0 


SECTION CODE 


VISITS 


NUMERIC 


4 


0 


NUMBER OF VISITS FOR SECTION CODE 
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APPENDIX B 



DISPLAY SCREENS 



LIST OF SCREENS 

ABSENCE SCREEN FILE 
APC SCREEN FILE 
CHOICE SCREEN FILE 
CMEALLOC SCREEN FILE 
CMEREQ SCREEN FILE 
CONFIRM SCREEN FILE 
DELCMERE SCREEN FILE 
DELLEAVE SCREEN FILE 
DELMOEXP SCREEN FILE 
DELQALLO SCREEN FILE 
EQUIPMENT SCREEN FILE 

EQUIPMENT UPDATE FROM RIP SCREEN FILE 

MOEXP SCREEN FILE 

OCCUPIED SCREEN FILE 

PERRIR_B SCREEN FILE 

PERSON SCREEN FILE 

POSITION SCREEN FILE 

QTRALLOC SCREEN FILE 

SOCIAL SCREEN FILE 

SURVEY SCREEN FILE 

TDA SCPXEN FILE 

TDAINPUT SCREEN FILE 

UPCMEREQ SCREEN FILE 



ABSENCE SCREEN FILE 



Update and change the absence information in the Personnel Database. 



6 


0, 


21 


SAY "UPDATE LEAVE OR ABSENCE REQUEST" 


0 


3, 


4 


SAY "This is the Fiscal Year" 


0 


3, 


28 


SAY ABSENCE->FY PICTURE "99" 


0 


3, 


31 


SAY "Leave or Absence request for ID CODE" 


0 


3, 


68 


SAY ABSENCE->IDCODE PICTURE "!9999" 


0 


6, 


23 


SAY "Type of Request" 


0 


6, 


46 


GET ABSENCE->TYPE PICTURE " ! " 


0 


8, 


4 


SAY "L-. Regular Leave E.. Emergency Leave 


0 


9, 


4 


SAY "P . . Permiss ive TDY C .. Convalescent Leave 


0 


13, 


11 


SAY "Starting Date" 


0 


13, 


26 


GET ABSENCE ->START 


0 


13, 


38 


SAY "Ending Date" 


0 


13, 


51 


GET ABSENCE->END 


0 


15, 


26 


SAY "Duration" 


0 


15, 


35 


SAY ABSENCE->DURATION PICTURE "999" 


0 


15, 


39 


SAY "days" 


0 


18, 


13 


SAY "COMMENT" 


0 


18, 


25 


GET ABSENCE->COMMENT FUNCTION " ! " 


0 


2, 


1 


TO 4, 75 


0 


7, 


2 


TO 10, 72 



T. .Other 
O. .Other 



APC SCREEN FILE 



Update and chance the Account 



Processina Code informal-ion 



in the Budr 



0 


2, 


23 


SAY 


0 


2, 


44 


SAY 


0 


5, 


8 


SAY 


0 


5, 


20 


GET 


0 


5, 


48 


SAY 


0 


5, 


63 


GET 


0 


8/ 


20 


SAY 


0 


8, 


38 


GET 


0 


11, 


20 


SAY 


0 


11, 


38 


GET 


0 


14, 


31 


SAY 


0 


15, 


30 


SAY 



"APC Code Entered ->" 

APC->APC FUNCTION "R" PICTURE "A-999" 
"SECTION" 

APC->SECTION 
"Section Code" 

APC->S_CODE 
"Point of Contact" 

APC->POC 

"Telephone Number" 

APC->TELEPHONE PICTURE "( 999 ) -999-9999 " 
" Sec" 

"SECTION CODES" 



TDY, not CME" 



ret Database. 
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0 


16, 


4 


SAY 


"Family Practice Clinic 


FFC 


Consolidated Troop Clinic 


CTM" 


0 


17, 


4 


SAY 


"General Outpatient Clinic 


GOC 


Fort Hunter Liggett Clinic 


FHL" 


0 




4 


SAY 


"^'TMC-Family Practice 


CFP 


Ambulance Section 


AMB" 


0 


19, 


4 


SAY 


"Emergency Medical Service 


EMS 


Flight Suigeon Office 


FSO" 


0 


20, 


4 


SAY 


"Presidio of Monterey 


POM 


Department 


DEP" 


0 


1, 


1 


TO 


13, 78 DOUBLE 








0 


3, 


2 


TO 


3, 77 








0 


14, 


1 


TO ; 


21, 78 









CHOICE SCREEN FILE 

Generic user selection format for the Personnel Datcibase. 

0 6,0 TO 11, 79 DOUBLE 
0 7,10 SAY "ENTER YOUR CHOICE" 

0 8,10 SAY "1. MOVE THE OLD PERSON TO EXCESS AND THE NEW PERSON INTO THE SLOT" 

0 9,10 SAY "2. PLACE THE PERSON YOU ARE WORKING WITH INTO THIS POSITION AS EXCESS ( OVERSTPENGTH, 
POSITION CODE = 99)" 

0 10,10 SAY "3. TRY ANOTHER POSITION " 

0 7,28 GET ANSWER PICTURE "9" RANGE 1,3 



CMEALLOC SCREEN FILE 



Update and change the Continuing Medical Information funds allocation in Personnel Database. 



0 1, 28 SAY "UPDATE CME ALLOCATION" 

0 5, 9 SAY "THE CME ALLOCATION FOR FISCAL YEAR" 

0 5, 44 SAY CMEALLOC->FY 

0 5, 47 SAY "SHOULD BE $" 

0 5, 59 GET CMEALLOC->ALLOCATION 

0 3, 5 TO 7, 73 DOUBLE 



CMEREQ SCREEN FILE 



Update and change the CME request information in the Personnel Database. 



0 


1, 


2 


SAY 


0 


1, 


68 


SAY 


0 


3, 


0 


SAY 


0 


3, 


34 


GET 


0 


4, 


3 


SAY 


0 


6, 


0 


SAY 


0 


6, 


46 


SAY 


0 


6, 


52 


SAY 


0 


8, 


0 


SAY 


0 


8, 


24 


GET 


0 


8, 


45 


SAY 


0 


8, 


71 


GET 


0 


10, 


0 


SAY 


0 


10, 


16 


GET 


0 


10, 


42 


SAY 


0 


10, 


60 


GET 


0 


11, 


42 


SAY 


0 


13, 


0 


SAY 


0 


13, 


31 


GET 


0 


13, 


41 


SAY 


0 


13, 


53 


GET 


0 


14, 


3 


SAY 


0 


14, 


14 


SAY 


0 


14, 


19 


SAY 


0 


16, 


0 


SAY 


0 


16, 


18 


GET 


0 


16, 


29 


SAY 


0 


16, 


44 


GET 


0 


16, 


56 


SAY 


0 


16, 


71 


GET 


0 


18, 


17 


SAY 


0 


18, 


40 


SAY 


0 


20, 


12 


SAY 


IF C 


CODE 


i = "i 




0 


20, 


33 ; 


ELSE 








0 


20, 


33 ; 



"SUBJECT: APPLICATION FOR CONFERENCE/MISSION TRAVEL IN FISCAL YEAR" 

M_FY PICTURE "99" 

"1. Type of Travel Requested " 

CMEREQ->TYPE PICTURE " ! " 

"C-Conf erence/Meet ing Travel G-General Mission Travel B-Board Cert if icatio" 
"2. ID CODE of person requesting the travel is" 

M_IDCODE PICTURE "!9999" 

n n 

"4. Purpose of Travel is" 

CMEREQ->PURPOSE 
". 5. Registration Fee $" 

CMEREQ->REGFEE 
"6. Destination" 

CMEREQ->LOCATION 
"Mode of Travel is" 

CMEREQ->TVLMODE 

"F-FLY, G-GOVT VEH, P-POV, O-OTHER" 

"8. Leave Dates Starting Date" 

CMEREO->START 
"Ending Date" 

CMEREQ->END 
"Duration " 

CMEREQ- >DURAT I ON 
"days" 

"13. TRAVEL COST $" 

CMEREQ->TRAVELCOST 
"PER DIEM COST $" 

CMEREQ->PERDIEM 
"REIMBURSABLES $" 

CMEREQ->REIMB 
"TOTAL COST OF TRAVEL $" 

CMEREQ->TOTALCOST 
"EXPENSES REFLECT THE" 

SAY "ACTUAL COST OF TRAVEL" 

SAY "ESTIMATED COST OF TRAVEL" 
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END IF 

00, 0 TO 2, 79 

0 1<^, in TO 21, 59 



CONFIRM SCREEN FILE 

Generic confirmation screen for the Personnel Database. 

0 4,0 SAY MESSAGE 
0 6,0 TO 9,79 DOUBLE 
0 7,5 SAY "Last Name: "+LNAME 
0 7,35 SAY "First Name; "+FNAME 
0 8,5 SAY "Rank: "+RANK 
0 8,35 SAY "Branch: "+BRANCH 
?? CHR(7) 

0 15,0 

WAIT "PRESS RETURN TO CONTINUE..." 



DELCMERE SCREEN FILE 



Special delete CME request information screen in Personnel Database. 

SUBJECT: DELETE APPLICATION FOR CONFEPENCE/MISS ION TRAVEL IN FISCAL YEAR" 
M__FY PICTURE "99" 

1. Type of Travel Requested " 

CMEREQ->TYPE PICTURE " ! " 

C-Conference/Meeting Travel G-General Mission Travel B-Board Certif icatio" 

2. ID CODE of person requesting the travel is" 

CMEREQ->IDCODE PICTURE " ! 9999" 

4. Purpose of Travel is" 

CMEREQ->PURPOSE 
. 5. Registration Fee $" 

CMEREQ->REGFEE 
6. Destination" 

CME REQ- > LOC AT I ON 
Mode of Travel is" 

CMEREQ- >T VLMODE 

F-FLY, G-GOVT VEH, P-POV, O-OTHER" 



0 


1, 


2 


SAY 




0 


L 


68 


SAY 




0 


3, 


0 


SAY 


n 


0 


3, 


34 


SAY 




0 


4, 


3 


SAY 


" 


0 


6, 


0 


SAY 




0 


6, 


46 


SAY 




0 


6, 


52 


SAY 




0 


8, 


0 


SAY 


n 


0 


8, 


24 


SAY 


1 


0 


8, 


45 


SAY 




0 


8, 


71 


SAY 


1 


0 


10, 


0 


SAY 


n 


0 


10, 


16 


SAY 


1 


0 


10, 


42 


SAY 


"1 


0 


10, 


60 


SAY 




0 


11, 


42 


SAY 




0 


13, 


0 


SAY 


" 


0 


13, 


31 


SAY 




0 


13, 


41 


SAY 




0 


13, 


53 


SAY 


1 


0 


14, 


3 


SAY 


"1 


0 


14, 


14 


SAY 




0 


14, 


19 


SAY 


", 


0 


16, 


0 


SAY 


n 


0 


16, 


18 


SAY 


1 


0 


16, 


29 


SAY 




0 


16, 


44 


SAY 


1 


0 


16, 


56 


SAY 


n 


0 


16, 


71 


SAY 


1 


0 


18, 


17 


SAY 




0 


18, 


40 


SAY 


T< 


0 


20, 


17 


SAY 

GET 


"1 

1 


0 


0, 


0 


TO 


2 


0 


19, 


10 


TO 21 



8. Leave Dates 
CMEREQ-> START 
Ending Date" 
CMEREQ->END 



Starting Date" 



CMEREQ->DURATION 
days " 

13. TRAVEL COST $" 
CMEREQ->TRAVELCOST 
PER DIEM COST $" 
CMEREO->PERDIEM 
REIMBURSABLES $" 
CMEREQ->REIMB 



DO YOU WANT TO DELETE THIS RECORD" 
MAYBE PICTURE " ! " 

, 79 
, 58 



DELLEAVE SCREEN FILE 



Special delete Absence information screen for the Personnel Database. 



0 


0, 


21 


SAY 


0 


3, 


4 


SAY 


0 


3, 


28 


SAY 


0 


3, 


31 


SAY 


0 


3, 


68 


SAY 


0 


6, 


23 


SAY 


0 


6, 


46 


SAY 



"UPDATE LEAVE OR ABSENCE REQUEST" 

"This is the Fiscal Year" 

ABSENCE->FY PICTURE "99" 

"Leave or Absence request for ID CODE" 
ABSENCE~>IDCODE PICTURE "!9999" 

"Type of Request" 

ABSENCE->TYPE PICTURE " ! " 
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0 


8, 


4 


SAY 


"L.. Regular Leave 


E. .Emergency Leave 


0 


9, 


4 


SAY 


"P .. Permissive TDY 


C. .Convalescent Leave 


0 


1 


n 


SAY 


"Starting Date" 




0 


13, 


26 


SAY 


ABSENCE->START 




0 


13, 


38 


SAY 


"Ending Date" 




0 


13, 


51 


SAY 


ABSENCE->END 




0 


15, 


26 


SAY 


"Duration" 




0 


15, 


35 


SAY 


ABSENCE->DURATION 


PICTURE "999" 


0 


15, 


39 


SAY 


"days " 




0 


18. 


13 


SAY 


"COMMENT" 




0 


18, 


25 


SAY 


ABSENCE ->COMMENT 




0 


2, 


1 


TO 


4, 75 




0 


7. 


2 


TO 10, 72 




0 


22, 


17 


SAY 

GET 


"DO YOU WA15T TO DELETE THIS RECORD"; 
MAYBE PICTURE "1" 


0 


CM 


10 


TO 23, 58 





T.. other TOY, not CME" 
O. .Other " 



DELMOEXP SCREEN FILE 



Special delete Monthly Expenditure format for the Budget Database. 



0 


2, 


20 


SAY "Delete this Monthly Expenditure" 


0 


5, 


26 


SAY "APC Code" 


0 


5, 


38 


SAY MOEXP->APC FUlJCTION "!" PICTURE 


0 


7, 


26 


SAY "Month" 


0 


7, 


38 


SAY MOEXP->MONTH 


0 


9, 


26 


SAY "Expenses" 


0 


9, 


38 


SAY MOEXP->EXPENSES 


0 


4, 


15 


TO 10, 56 DOUBLE 


0 


18, 


14 


TO 20,59 


0 


19, 


19 


SAY "Delete this Record? (Y/N) "; 



GET Maybe PICTURE "1" 



DELQALLO SCREEN FILE 



Special delete quarterly allocation format for the Budget Database. 



0 


3, 


19 


SAY "Delete the Quarterly Allocati^ 


0 


4, 


34 


SAY "for" 


0 


5, 


28 


SAY "Fiscal Year" 


0 


5, 


41 


SAY QTRALLOC->FY 


0 


9, 


27 


SAY "Quarter" 


0 


9, 


39 


SAY QTRALLOC->QUARTER 


0 


11, 


27 


SAY "APC Code" 


0 


11, 


39 


SAY QTRALLOC->APC 


0 


13, 


27 


SAY "Allocation" 


0 


13, 


39 


SAY QTRALLOC->ALLOCATION 


0 


1, 


14 


TO 16, 59 DOUBLE 


0 


7, 


15 


TO 7, 58 


0 


18, 


14 


TO 20, 59 


0 


19, 


19 


SAY "Delete this Record? (Y/N) "; 



GET Maybe PICTURE "I" 



EQUIPMENT SCREEN FILE 



Update and change the Equipment 
[EMENU1_1 SCREEN FILE) 



0 


2, 


17 


SAY 


"ENTER N E 


0 


4, 


25 


SAY 


"EQUIPMENT C^DE # 


0 


4, 


44 


GET 


EQUIP ->EQCODE 


0 


6 , 


2 


SAY 


"SECT DATE 


0 


7, 


2 


GET 


EQUIP->SECTCODE 


0 


7, 


7 


GET 


EQUIP ->REQDATE 


0 


7, 


17 


GET 


EQUIP->DESCRIPT 


0 


7, 


42 


GET 


EQUIP ->REQTYPE 


0 


7, 


52 


GET 


EQUIP “>URGCODE 


0 


7, 


60 


GET 


EQUIP->QTY 


0 


7, 


67 


SAY 




0 


7, 


69 


GET 


EQUIP->UNITPRICE 


0 


9, 


21 


SAY 


"STATUS CODE 


0 


10, 


26 


GET 


EQUIP ->STATUS 



information in the Equipment 
W EQUIPMENT DAT 
ITEM DESCRIPTION TYPE 

COMMENTS" 



Database . 

A" 

URGENCY QTY UNIT PRICE" 
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0 


10, 


41 


GET 


EQUIP ->COMMENTS 










0 


14, 


7 


SAY 


"URGENCY CODES 


TYPE OF PEQUEST CODES 


STATUS CODES" 


0 


1^, 


6 


s;^Y 


"0 




Needed Now 


MEL’C 


MEDCASE 


PW 


Paperwork 


0 


17, 


6 


SAY 


"1 




1 Year 


CEEP 


CEEP 


PJl 


PJID " 


0 


18, 


6 


SAY 


"2 




2 Years 


CAPR 


CAPR 


AP 


Approved 


0 


19, 


6 


SAY 


"3 




3 Years 


OTHE 


OTHER 


OO 


On Order" 


0 


20, 


6 


SAY 


"4 




Not Urgent 






RC 


Received" 


0 


13, 


4 


TO 


21, 


22 












0 


13, 


28 


TO 


21, 


52 












0 


15, 


29 


TO 


15, 


51 












0 


15, 


5 


TO 


15, 


21 












0 


1/ 


0 


TO 


11, 


79 


DOUBLE 










0 


3, 


1 


TO 


3, 


78 












0 


13, 


58 


TO 


21, 


75 












0 


15, 


59 


TO 


15, 


74 












0 


5, 


24 


TO 


5, 


51 













EQUIPMENT UPDATE FROM RIR SCREEN FILE 



Special update screen for Equipment when the Resource Information Report is used. 
[EMENU2_2 SCREEN FILE] 



0 


3, 


31 


SAY "SECTION" 


0 


3, 


42 


SAY EQUIP->SECTCODE 


0 


6, 


9 


SAY "EQUIP CODE ITEM 


0 


7, 


10 


SAY EQUIP ->EQCODE 


0 


7, 


21 


SAY EQUIP->DESCRIPT 


0 


7, 


44 


GET EQUIP->QTY 


0 


7, 


50 


GET EQUIP->UNITPRICE 


0 


7, 


64 


GET EQUIP->STATUS 


0 


10, 


33 


SAY "COMMENTS" 


0 


11, 


27 


GET EQUIP ->COMMENTS 


0 


14, 


12 


SAY "Press ESC to abort 


0 


2, 


5 


TO 13, 71 DOUBLE 


0 


4, 


6 


TO 4, 70 



DESCPIPTION QTY UNITPRICE STATUS" 



editing, ENTER to complete changes." 



MOEXP SCREEN FILE 



Update and change the monthly expenditures in the Budget Database. 



0 


2, 


22 


SAY "Enter the Monthly Expenditure" 


0 


5, 


26 


SAY "APC Code" 


0 


5, 


38 


SAY MOEXP ->APC FUNCTION " ! " PICTURE 


0 


7, 


26 


SAY "Month" 


0 


7, 


38 


SAY MOEXP ->MONTH 


0 


9, 


26 


SAY "Expenses" 


0 


9, 


38 


GET MOEXP->EXPENSES 


0 


4, 


15 


TO 10, 56 DOUBLE 


0 


21, 


15 


TO 24, 56 



OCCUPIED SCREEN FILE 



Special output screen when a TDA position is occupied in the Personnel Database. 
0 6,0 TO 11,79 DOUBLE 

0 7,5 SAY "THAT POSITION IS ALREADY OCCUPIED BY: " 

0 8,5 SAY "Last Name: "+LNAME 
0 9, 5 SAY "First Name: "+FNAME 
0 10,5 SAY "Rank: "+RAi^K 
0 15,0 
WAIT 



PERRIR B SCREEN FILE 



Special input 



screen for personnel information when the Resource Information Report is Used. 



0 


1, 


24 


SAY "UPDATE FROM R.I.P. 


REPORT" 






0 


3, 


0 


SAY "B. CHANGES TO CURRENT TDA 


(OTHER THAN LOSSES 


OR GAINS) " 


0 


5, 


22 


SAY "OLD POSITION 




NEW 


POSITION" 


0 


7, 


2 


SAY "PARA LINE POSN 


IDCODE 


LAST NAME 


RANK 


0 


9, 


3 


GET O TDA PAPA PICTURE 


" 999 " 







PAPA 



LINE 



POSN" 
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0 


9, 


10 


GET 


0 


TDA LINE PICTURE "99" 


0 


9, 


17 


GET 


0 


TDA POSN PICTURE "99" 


0 




23 


GET 


M 


IDCODE PICTURE "!9999" 


0 


9, 


31 


GET 


M 


LNAME PICTURE "!!!!!!!!!!!!!!!!!!!!" 


0 


9, 


55 


GET 


M 


RANK PICTURE " ! ! ! " 


0 


9, 


62 


GET 


M 


TDA PARA PICTURE "999" 


0 


9, 


69 


GET 


M 


TDA LINE PICTURE "99" 


0 


9r 


76 


GET 


M 


TDA POSN PICTURE "99" 


0 


13, 


18 


SAY 


"PRESS RETURN (BLANK ALL ENTRIES) TO QUIT" 


0 


7r 


7 


TO 


9, 


7 


0 


If 


14 


TO 


9, 


14 


0 


If 


21 


TO 


9, 


21 


0 


7, 


29 


TO 


9, 


29 


0 


If 


52 


TO 


9, 


52 


0 


If 


66 


TO 


9, 


66 


0 


7, 


73 


TO 


9, 


73 


0 


5, 


59 


TO 


9, 


59 DOUBLE 


0 


4, 


0 


TO 10, 


79 DOUBLE 


0 


6, 


1 


TO 


6, 


78 


0 


8, 


1 


TO 


8, 


78 


0 


0, 


21 


TO 


2, 


52 



PERSON SCREEN FILE 



Update and change personnel information in the Personnel Database. 



0 


0, 


28 


SAY 


"UPDATE PERSONNEL" 




0 


2, 


4 


SAY 


"ID CODE is" 




0 


2, 


15 


SAY 


PERSON -> IDCODE 




0 


4, 


5 


SAY 


"Last Name 


] 


0 


5, 


5 


GET 


PERSON -> LNAME 




0 


5, 


28 


GET 


PERSON ->FNAME 




0 


5, 


48 


GET 


PERSON ->RANK 




0 


5, 


56 


GET 


PERSON->BPANCH 




0 


5, 


65 


GET 


PERSON->MOS 




0 


8, 


5 


SAY 


"Arrival Date " 




0 


8, 


23 


GET 


PERSON->ARRDATE 




0 


8, 


38 


SAY 


"Anticipated Date of 


Los; 


0 


8, 


65 


GET 


PERSON->ALOSS 




0 


12, 


18 


SAY 


"INDIVIDUAL IS ASSIGNED ' 


0 


14, 


23 


SAY 


"TDA Paragraph Number 


is 


0 


14, 


47 


SAY 


P EPSON ->TDA_PARA 




0 


15, 


23 


SAY 


"TDA Line Number is" 




0 


15, 


42 


SAY 


PERSON->TDA_LINE 




0 


16, 


23 


SAY 


"TDA Position Number 


is " 


0 


16, 


46 


SAY 


PERSON->TDA POSN 




0 


18, 


6 


SAY 


"NOTE: If Position Numbe 


0 


13, 


16 


TO 17, 57 




0 


6, 


4 


TO 


6, 74 




0 


4, 


53 


TO 


5, 53 




0 


4, 


62 


TO 


5, 62 




0 


4, 


45 


TO 


5, 45 




0 


4, 


26 


TO 


5, 26 




0 


3, 


3 


TO 10, 75 DOUBLE 





First Name MI 



RANK 



BRANCH 



MOS" 



is 99, the Individual is carried as excess' 



PCSSITION SCREEN FILE 

TDA position verification output screen for the Personnel Database. 
0 12,0 TO 17,79 DOUBLE 

0 23,5 SAY "THE POSITION CHOSEN WAS; " 

0 14,5 SAY "Job Title: "+JOB_TITLE 
0 15,5 SAY "Authorized Branch; 

0 15,30 SAY "Authorized Grade; "+AUIH_GR 
0 IS, 5 SAY "Authorized MOS; "+AUTH_MOS 
0 16,30 SAY "Authorized Position: " 

IF AUTH = 1 

?? "YES" 

ELFE 

?? "NO" 

ENDIF 

0 22,0 WAIT 
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QTRALT.OC SCREEN FILE 

Update and change quarterly allocation in the Budget Database. 



0 


3, 


19 


SAY 


"Enter the New Quarterly Allocation" 


0 


4, 


34 


SAY 


"for" 


0 


5, 


28 


SAY 


"Fiscal Year" 


0 


5, 


41 


SAY 


QTRALLOC->FY 


0 


9, 


27 


SAY 


"Quarter" 


0 


9, 


39 


SAY 


QTRALLOC->QUARTER 


0 


11. 


27 


SAY 


"APC Code" 


0 


11. 


39 


SAY 


QTRALLOC->APC 


0 


13, 


27 


SAY 


"Allocation" 


0 


13, 


39 


GET 


QTRALLOC->ALLOCATION 


0 


1. 


14 


TO 16, 59 DOUBLE 


0 


7, 


15 


TO 


7, 58 



SOCIAL SCREEN FILE 



Update and change personal information in the Personnel Database. 



0 


1. 


12 


0 


1. 


57 


0 


3, 


28 


0 


4, 


0 


0 


5, 


3 


0 


6. 


3 


0 


8 , 


0 


0 


9, 


3 


0 


11. 


2 


0 


11. 


13 


0 


11. 


38 


0 


11. 


50 


0 


13, 


2 


0 


13, 


25 


0 


13, 


45 


0 


13, 


47 


0 


13, 


51 


0 


15, 


18 


0 


15, 


35 


0 


17, 


2 


0 


17, 


14 


0 


17, 


29 


0 


17, 


52 


0 


19, 


10 


0 


19, 


27 


0 


0. 


0 


0 


10, 


0 



SAY "This is the personal information for ID CODE" 

SAY PRIVATE->IDCODE PICTURE "19999" 

SAY "PRIVACY ACT STATEMENT" 

SAY "PRINCIPLE PURPOSE: To maintain personal information on tndivduals assigned to" 
SAY "this command to facilitate counseling, emergency notification, and social" 

SAY "event information." 

SAY "WARNING: This information is of a highly sensitive nature and should not be" 
SAY "provided to anyone outside of the chain of command without approval." 

SAY "Address" 

GET PRIVATE->ADDRESS FUNCTION " ! " 

SAY "Telephone" 

GET PRIVATE->TELEPHONE FUNCTION "R" PICTURE "(999)999-9999* 

SAY "City, State, Zip Code" 

GET PRIVATE->CITY 
SAY " , " 

GET PRIVATE->STATE 

GET PRIVATE->ZIPCODE FUtJCTION "R" PICTURE "99999-9999" 

SAY "Date of Rank" 

GET PRIVATE->DOR 
SAY "Wife's Name" 

GET PRIVATE->WIFE 

SAY "Children's Names/Ages" 

GET PRIVATE->CHILDPF:N function "S24" 

SAY "Comments" 

GET PRIVATE->COMMENTS 
TO 2, 77 
TO 20, 77 



SURVEY SCREEN FILE 

Input screen for the Patient Satisfaction Survey in the Satisfaction Database. 



0 


1. 


7 


SAY 


"MONTH" 




0 


1. 


13 


GET 


SURVEY->MONTH RANGE 1, 12 




0 


1. 


18 


SAY 


"YEAR" 




0 


1. 


23 


GET 


SURVEY->YEAR 




0 


1. 


29 


SAY 


"CLINIC" 




0 


1. 


36 


GET 


SUPVEY->SErTCODE 




0 


1. 


43 


SAY 


"DOCTOR" 




0 


1. 


51 


GET 


SURVEY->DOCTORNAME 




0 


3, 


18 


SAY 


"l.A. Days to get appointment. 


l.A 


0 


3, 


58 


GET 


SURVEY->APPTDAYS RANGE 1, 6 




0 


4, 


20 


SAY 


"B. Acceptability. 


B. " 


0 


4, 


58 


GET 


SURVEY->ACCAPPT RANGE 1, 2 




0 


8, 


18 


SAY 


"2. Records ready on time. 


2 . " 


0 


6, 


58 


GET 


SURVEY ->RECORDS RANGE 1, 2 




0 


8, 


18 


SAY 


"3. A. Waiting time. 


3. A 


0 


8, 


58 


GET 


SURVEY->WAITTIME RANGE 1, 4 




0 


9, 


2S> 


SAY 


"B. Acceptability. 


B. " 


0 


9, 


58 


GET 


SURVEY- >ACCWAIT RANGE 1, 2 
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0 


11. 


18 


SAY "4. Courtesy, receptionists. 


4 . " 


0 


11. 


58 


GET SURVEY->RECEPT RANGE 1, 5 




0 


JC. 


18 


SAY "5. Courtesy, nurses. 


5. " 


0 


12, 


58 


GET SURVEY->NURSE RANGE 1, 5 




0 


13, 


18 


SAY "6. Courtesy, doctors. 


6. " 


0 


13, 


58 


GET SURVEY->DOCTORS RANGE 1, 5 




0 


14, 


18 


SAY "7. Explanation of procedures. 


7." 


0 


14, 


58 


GET SURVEY->EXPLAIN RANGE 1, 5 




0 


15, 


18 


SAY "8. Time spent with doctor. 


8." 


0 


15, 


58 


GET SURVEY->TIMESPENT RANGE 1, 5 




0 


16, 


18 


SAY "9. Cleanliness. 


9. " 


0 


16, 


58 


GET SURVEY->CLEAN RANGE 1, 5 




0 


17, 


17 


SAY "10. General satisfaction. 


10. " 


0 


17, 


58 


GET SURVEY->SATIS RANGE 1, 5 




0 


20, 


20 


SAY "ARE THERE COMMENTS TO ADD? (Y/N) 


n 


0 


20, 


58 


GET SURVEY->PATCOMMENT 




0 


21, 


19 


SAY " (Cntrl PgDn to Enter Comments) " 




0 


21, 


55 


GET SURVEY ->COMMENTS 




0 


0, 


4 


TO 22, 73 DOUBLE 




0 


2, 


15 


TO 10, 60 




0 


10, 


15 


TO 18, 60 





TDA SCREEN FILE 

Update and change the TDA information in the Personnel Database. 



0 


2, 


15 


SAY 


"TDA Listing" 


0 


4, 


10 


SAY 


"Paragraph Number" 


0 


4, 


27 


SAY 


TDA->TDA PARA 


0 


4, 


54 


SAY 


"POSITION TITLE" 


0 


6, 


10 


SAY 


"Line Number" 


0 


6, 


28 


SAY 


TDA->TDA LINE 


0 


6, 


47 


SAY 


"Job Title" 


0 


6, 


59 


GET 


TDA->JOB_TITLE 


0 


8, 


10 


SAY 


"Position Number" 


0 


8, 


28 


SAY 


TDA->TDA POSN 


0 


12, 


26 


SAY 


"POSITION CHARACTERISTICS 


0 


14, 


24 


SAY 


"APC Code" 


0 


14, 


46 


GET 


TDA->APC 


0 


15, 


24 


SAY 


"Authorized Branch" 


0 


15, 


46 


GET 


TDA->AUTH_BR 


0 


16, 


24 


SAY 


"Authorized Grade" 


0 


16, 


46 


GET 


TDA->AUTH_GR 


0 


17, 


24 


SAY 


"Authorized MOS" 


0 


17, 


46 


GET 


TDA->AUTH_MOS 


0 


18, 


24 


SAY 


"Position Authorized" 


0 


18, 


46 


GET 


TDA->AUTH 


0 


19, 


29 


SAY 


"1=YES 0=NO" 


0 


3, 


7 


TO 


9, 34 


0 


6, 


35 


TO 


6, 44 


0 


5, 


45 


TO 


7, 79 


0 


13, 


21 


TO 20, 55 



TDAINPUT SCREEN FILE 



Input screen for entering a requested TDA position in the PErsonnel Database. 
0 6,0 TO 11,79 DOUBLE 

0 7,5 SAY "WHAT POSITION WILL THIS PERSON OCCUPY ; 

OR ENTER A ZERO (0) TO QUIT: " 

0 8,5 SAY "TDA Paragraph Number:" ; 

GET M_TDAPARA PICTURE "999" 

READ 

*- SEE IF THEY WANT TO QUIT 
IF M_IDAPARA = 0 
TRY-.F. 

LOOP 
END IF 

0 9,5 SAY "TDA Line Number:" ; 

GET M_TDALINE PICTURE "99" 

0 10,5 SAY "TDA Position Number:" ; 

GET M TDAPOSN PICTURE "99" 
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UPCMF.REQ SCREEN FILE 

Special update screen for CME requests when only actual costs are entered in Personnel Database. 



0 


1, 2 


SAY 


"SUBJECT: APPLICATION 


FOR CONFERENCE /MIS SION 


0 


1, 68 


SAY 


M FY PICTURE "99" 




0 


3, 0 


SAY 


"1. Type of Travel Requested " 


0 


3, 34 


SAY 


CMEREQ->TYPE PICTURE " ! " 


0 


4, 3 


SAY 


"C-Conference/Meet ing Travel G-General Miss; 


0 


e, 0 


SAY 


"2. ID CODE of person 


requesting the travel ; 


0 


6, 46 


SAY 


M IDCODE PICTURE " ! 


9999" 


0 


6, 52 


SAY 


" . " 




0 


8, 0 


SAY 


"4. Purpose of Travel 


is" 


0 


8, 24 


SAY 


CMEREQ“>PURPOSE 




0 


8, 45 


SAY 


5. Registration 


Fee $" 


0 


8, 71 


GET 


CMEREQ->REGFEE 




0 


10, 0 


SAY 


"6. Destination" 




0 


10, 16 


SAY 


CMEREQ->LOCATION 




0 


10, 42 


SAY 


"Mode of Travel is" 




0 


10, 60 


SAY 


CMEREQ->TVLMODE 




0 


11, 42 


SAY 


"F-FLY, G-GOVT VEH, P 


“POV, O-OTHER" 


0 


13, 0 


SAY 


"8. Leave Dates Starting Date" 


0 


13, 31 


SAY 


CMEREQ->START 




0 


13, 41 


SAY 


"Ending Date" 




0 


13, 53 


SAY 


CMEREQ->END 




0 


14, 3 


SAY 


"Duration" 




0 


14, 14 


SAY 


CMEREQ->DURATION 




0 


14, 19 


SAY 


"days " 




0 


16, 0 


SAY 


"13. TRAVEL COST $" 




0 


16, 18 


GET 


CMEREQ->TRAVELCOST 




0 


16, 29 


SAY 


"PER DIEM COST $" 




0 


16, 44 


GET 


CMEREQ->PERDIEM 




0 


16, 56 


SAY 


"REIMBURSABLES $" 




0 


16, 71 


GET 


CMEREQ->REIMB 




0 


18, 17 


SAY 


"TOTAL COST OF TRAVEL 


$" 


0 


18, 40 


SAY 


CMEREQ->TOTALCOST 




0 


20, 12 


SAY 


"EXPENSES REFLECT THE 




IF C CODE 


= 








0 20, 


33 


SAY "ACTUAL COST OF TRAVEL" 


ELSE 










0 20, 


33 SAY "ESTIMATED COST OF ' 


TRAVEL" 


ENDIF 








0 


0, 0 


TO 


2, 79 




0 


19, 10 


TO 21, 58 
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